Spring Boot @SpringBootTest

`@SpringBootTest` is used for Spring Boot integration tests that load an application context and verify how multiple Spring components work together. It is useful when a unit test with isolated mocks would not adequately exercise configuration, dependency wiring, or component integration.

`@SpringBootTest` tells Spring Boot's test framework to create an application context for the test. The context is built using the application's Spring Boot configuration, allowing beans such as controllers, services, repositories, configuration classes, and other components to participate in the test.

By default, the test does not necessarily start a real HTTP server. If the test needs HTTP-level behavior, `webEnvironment` can be configured, for example with `SpringBootTest.WebEnvironment.RANDOM_PORT`. Other modes include `MOCK`, `DEFINED_PORT`, and `NONE`.

Because context creation is more expensive than constructing a few objects in a unit test, `@SpringBootTest` should be used when integration between Spring-managed components is what you need to verify. For narrower tests, Spring provides more focused test annotations such as `@WebMvcTest` and `@DataJpaTest`.

Dependencies can still be replaced or controlled in integration tests. For example, Spring test facilities can provide mocks or test-specific configuration when calling an external system would be undesirable. The important distinction is that the test is exercising Spring's wiring and configuration rather than only testing one class in isolation.

Key points

• Loads a Spring application context for integration testing.
• Exercises real Spring bean wiring and configuration.
• Use `webEnvironment` when the test needs a web server.
• More expensive than a typical isolated unit test.
• Prefer narrower Spring test slices when full application integration is unnecessary.

Interview questions

What does `@SpringBootTest` do?

It tells Spring Boot to load an application context for a test. This lets the test use Spring-managed beans and verify that their configuration and dependencies work together. It is therefore broader than a normal unit test. The test can also be configured to start a web environment when HTTP behavior needs to be exercised.

When would you choose `@SpringBootTest` instead of a unit test with Mockito?

I would choose `@SpringBootTest` when the behavior depends on actual Spring configuration, bean wiring, converters, repositories, or interactions among several application layers. A Mockito-based unit test is better when I want fast feedback about one class in isolation. The integration test gives confidence that the components work together inside the Spring container. I would avoid using it when the additional context provides no value.

How can you make `@SpringBootTest` test HTTP endpoints?

The test can configure `webEnvironment`, such as `RANDOM_PORT`, to start the application on an automatically assigned port. The test can then use an HTTP client such as `TestRestTemplate` or another suitable client to send requests. This tests more of the application stack than directly calling a controller method. The chosen web environment should match the behavior the test needs to verify.

Why can a large suite of `@SpringBootTest` tests be slow?

Creating and initializing an application context is substantially more work than constructing a small set of objects for a unit test. Contexts may be reused when their configuration is compatible, but tests that require different configurations can lead to additional context creation. External infrastructure can add further startup and I/O costs. A balanced test suite therefore uses full-context tests selectively and relies on focused tests for narrower behavior.

What is the difference between `@SpringBootTest` and Spring test slices?

`@SpringBootTest` is intended for broad application integration and can load a large portion of the application's configuration. A test slice deliberately restricts the loaded components to a particular area, such as MVC or JPA. Slices can therefore provide faster and more focused tests. The choice depends on whether the behavior under test requires full application integration or only one technical layer.