Spring - Testing Flashcards
What are the main types of tests typically written in a Spring-based Java application, and how do they differ in scope and purpose?
1. Unit Tests
* Scope: Individual classes or methods, especially services, utility classes, or components without Spring context.
* Goal: Test logic in isolation.
* Tools: JUnit, Mockito.
* Spring Usage: Usually not required; avoid Spring context for speed.
2. Integration Tests
* Scope: Multiple components working together.
* Goal: Test real interaction between Spring beans, databases, REST clients, etc.
* Tools: @SpringBootTest, @DataJpaTest, @WebMvcTest.
* Spring Usage: Yes, loads Spring context (partially or fully).
3. End-to-End (E2E) / Acceptance Tests
* Scope: Full application stack, like calling REST endpoints and checking real DB responses.
* Goal: Validate the whole system behaves as expected.
* Tools: TestRestTemplate, RestAssured, Selenium (for UI).
* Spring Usage: Yes, full app context + infrastructure.
4. Slice Tests (Spring Boot Feature)
* Scope: Focused tests on layers (e.g., web, data).
* Goal: Faster than full @SpringBootTest, only loads a “slice” of the app.
* Examples:@WebMvcTest: Controllers + MVC layer.@DataJpaTest: JPA repositories + DB.@JsonTest: ObjectMapper and JSON (de)serialization.
5. Contract Tests
* Scope: Interaction between services, especially APIs.
* Goal: Ensure both provider and consumer agree on the request/response contract.
* Tools: Spring Cloud Contract, Pact.
* Spring Usage: Yes, for generating and verifying stubs/mocks and validating contracts.
* Use Case:
For the provider: verifies it conforms to the contract.
For the consumer: uses generated stubs to simulate provider.
What is the role of the @SpringBootTest annotation in testing, and when should you use it versus more focused alternatives like @WebMvcTest or @DataJpaTest?
The @SpringBootTest annotation is used to create integration tests that load the entire Spring application context, similar to what runs in production. It’s the most comprehensive way to test the system using actual Spring components.
=======
@SpringBootTest
Loads full Spring context: All beans, configurations, filters, properties, etc.
Used for:
* End-to-end testing of the full app.
* Testing business flows across multiple layers.
* When multiple Spring components need to collaborate.
* Testing CommandLineRunner or @Scheduled components.
Can be combined with:
* @AutoConfigureMockMvc: for testing HTTP endpoints with mocked servlet environment.
* @TestPropertySource: to override properties during the test.
* Test DBs or embedded servers (e.g., H2, Testcontainers).
=======
Alternatives:
@WebMvcTest
* Loads only the web layer: controllers, filters, @ControllerAdvice, etc.
* Use for: Testing REST endpoints, input validation, response serialization.
* Automatically mocks service layer.
@DataJpaTest
* Loads only the persistence layer (repositories, entities).
* Uses embedded DB by default.
* Use for: Testing queries, entity mappings, transactions.
How does Spring Boot support mocking dependencies in tests, and what are some common ways to replace real beans with mocks during test execution?
Spring Boot provides multiple ways to mock dependencies in tests, depending on whether you’re doing unit tests, slice tests, or integration tests with a real application context.
1. Manual mocking (Unit tests)
* Use Mockito or similar mocking frameworks.
* Since unit tests don’t use Spring context, you manually inject mocks using constructors or setters.
2. @MockBean (Spring context tests)
* Provided by Spring Boot.
* Replaces an existing bean in the Spring context with a Mockito mock.
* Works with @SpringBootTest, @WebMvcTest, @DataJpaTest, etc.
* Useful when you want to mock a dependency while still using the Spring context.
Example Use Cases:
* Mocking a service in a controller test (@WebMvcTest).
* Replacing an external API client in integration tests (@SpringBootTest).
3. @Mock + @InjectMocks (pure Mockito)
* Used for unit tests without Spring context.
* You annotate the class under test with @InjectMocks and its collaborators with @Mock.
4. Test configuration override
* Define a custom @TestConfiguration class with test-specific beans.
* Can use this to inject custom mocks or test doubles as real beans.
5. Profiles or Property-based mocking
* You can enable mock implementations conditionally using Spring profiles (@Profile(“test”)) or conditional beans (@ConditionalOnProperty).
* Useful when mocking third-party services like Kafka, Redis, etc., with embedded or fake implementations.
What is the difference between @WebMvcTest and @SpringBootTest + @AutoConfigureMockMvc, and when would you prefer one over the other?
@WebMvcTest
Loads only the web layer:
* Controllers
* @ControllerAdvice
* MVC configuration
Excludes service layer, repositories, etc.
Mocks non-web beans automatically unless explicitly provided using @MockBean.
Use when:
* You want to unit-test a controller in isolation.
* You only need to verify HTTP request/response handling, status codes, validation, headers, etc.
* Fast execution due to limited context.
======
@SpringBootTest + @AutoConfigureMockMvc
* Loads full application context, like production.
* @AutoConfigureMockMvc sets up MockMvc for making HTTP requests without a real server.
* You can test real beans — services, repositories, and controller logic together.**
Use when:
* You need to test integration of multiple layers (web, service, repo).
* You want to avoid starting the actual web server but still test HTTP endpoints.
* You want full Spring Boot behavior with real configurations.
In the context of Spring Boot testing, how does the @Transactional annotation affect test execution?
In Spring Boot testing, the @Transactional annotation wraps each test method in a transaction that is automatically rolled back (instead of committed) after the method completes. This behavior helps ensure that each test runs in a clean, isolated environment without polluting the database state for other tests.
When using @SpringBootTest and interacting with the database it is recommended to annotate the test class or methods with @Transactional to ensure automatic rollback and test isolation.
What is the use of @TestConfiguration in Spring Boot tests, and how does it differ from regular @Configuration?
@TestConfiguration is a special type of @Configuration in Spring Boot that is used to define test-specific beans. It behaves like @Configuration but is only picked up during testing, not in the main application context.
How does Spring Boot support testing with embedded databases, and what strategies can you use to ensure your database tests are fast, isolated, and production-representative?
Spring Boot offers strong support for embedded databases in testing, enabling fast, isolated, and self-contained tests that don’t rely on external infrastructure. These embedded DBs are ideal for testing JPA repositories, transactions, and data access logic.
=====
Common embedded DBs supported:
H2 (default, in-memory)
HSQLDB
Derby
=====
Strategies
1. Use @DataJpaTest (Recommended for repository testing)
Loads only persistence layer.
Automatically sets up an embedded DB.
Transactional with rollback — fast and isolated.
2. Use embedded DB with @SpringBootTest
Manually configure the embedded DB via application-test.yml or @TestPropertySource.
Useful for full-stack integration tests with actual DB logic.
3. Testcontainers (for production-like DB)
Runs real database instances in Docker (e.g., Postgres, MySQL).
Ideal when you need:
* DB-specific features
* Accurate SQL behavior
* Schema compatibility
What is the role of @MockBean in Spring Boot tests, and how does it differ from using @Mock or manually defined mock instances?
-
@MockBeanis a Spring Boot testing annotation that allows you to mock and inject a bean into the Spring application context, replacing any existing bean of the same type. It’s tightly integrated with Spring’s test context and works with @SpringBootTest, @WebMvcTest, and other test annotations that load the context. -
@Mockcreates a plain Mockito mock that is NOT context-aware.
What is Spring Cloud Contract, and how does it help with contract testing between microservices?
Spring Cloud Contract ensures that providers and consumers agree on the structure and behavior of API contracts by automating the generation and verification of stubs and tests.
Purpose
* Ensure that producers (API providers) and consumers (clients) are aligned on the expected input/output of HTTP or messaging interfaces.
* Prevent integration issues caused by mismatched expectations.
* Allow faster development with confidence and automation.
What are Testcontainers, and how do they enhance integration testing in Spring Boot applications?
Testcontainers is a Java library that provides lightweight, disposable Docker containers for use in integration tests. It allows Spring Boot tests to run against real services (e.g., PostgreSQL, Kafka, Redis) in isolated environments, improving test realism while maintaining automation and repeatability.
What is the difference between using MockMvc and TestRestTemplate in Spring Boot tests, and when would you use each?
MockMvc
* Simulates HTTP requests without starting the actual server.
* Uses Spring’s DispatcherServlet in a mock environment.
* Fast and lightweight — ideal for controller-layer or slice tests.
* Works well with @WebMvcTest or @SpringBootTest + @AutoConfigureMockMvc.
* Supports fluent API for assertions (status, headers, body, etc.).
* No real networking — just internal servlet simulation.
TestRestTemplate
* Sends real HTTP requests to the running application.
* Requires the app to run on a random port (@SpringBootTest(webEnvironment = RANDOM_PORT)).
* Slower — but tests the app as a black box.
* Useful for end-to-end integration tests with full stack (controller → service → repo).
* More closely resembles real client behavior.
