[[testing.spring-boot-applications]]
= Testing Spring Boot Applications

A Spring Boot application is a Spring javadoc:org.springframework.context.ApplicationContext[], so nothing very special has to be done to test it beyond what you would normally do with a vanilla Spring context.

NOTE: External properties, logging, and other features of Spring Boot are installed in the context by default only if you use javadoc:org.springframework.boot.SpringApplication[] to create it.

Spring Boot provides a javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] annotation, which can be used as an alternative to the standard `spring-test` javadoc:org.springframework.test.context.ContextConfiguration[format=annotation] annotation when you need Spring Boot features.
The annotation works by xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.detecting-configuration[creating the javadoc:org.springframework.context.ApplicationContext[] used in your tests through javadoc:org.springframework.boot.SpringApplication[]].
In addition to javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] a number of other annotations are also provided for xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-tests[testing more specific slices] of an application.

TIP: If you are using JUnit 4, do not forget to also add `@RunWith(SpringRunner.class)` to your test, otherwise the annotations will be ignored.
If you are using JUnit 5, there is no need to add the equivalent `@ExtendWith(SpringExtension.class)` as javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] and the other `@...Test` annotations are already annotated with it.

By default, javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] will not start a server.
You can use the `webEnvironment` attribute of javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] to further refine how your tests run:

* `MOCK`(Default) : Loads a web javadoc:org.springframework.context.ApplicationContext[] and provides a mock web environment.
Embedded servers are not started when using this annotation.
If a web environment is not available on your classpath, this mode transparently falls back to creating a regular non-web javadoc:org.springframework.context.ApplicationContext[].
It can be used in conjunction with xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.with-mock-environment[`@AutoConfigureMockMvc` or javadoc:org.springframework.boot.test.autoconfigure.web.reactive.AutoConfigureWebTestClient[format=annotation]] for mock-based testing of your web application.
* `RANDOM_PORT`: Loads a javadoc:org.springframework.boot.web.context.WebServerApplicationContext[] and provides a real web environment.
Embedded servers are started and listen on a random port.
* `DEFINED_PORT`: Loads a javadoc:org.springframework.boot.web.context.WebServerApplicationContext[] and provides a real web environment.
Embedded servers are started and listen on a defined port (from your `application.properties`) or on the default port of `8080`.
* `NONE`: Loads an javadoc:org.springframework.context.ApplicationContext[] by using javadoc:org.springframework.boot.SpringApplication[] but does not provide _any_ web environment (mock or otherwise).

NOTE: If your test is javadoc:org.springframework.transaction.annotation.Transactional[format=annotation], it rolls back the transaction at the end of each test method by default.
However, as using this arrangement with either `RANDOM_PORT` or `DEFINED_PORT` implicitly provides a real servlet environment, the HTTP client and server run in separate threads and, thus, in separate transactions.
Any transaction initiated on the server does not roll back in this case.

NOTE: javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] with `webEnvironment = WebEnvironment.RANDOM_PORT` will also start the management server on a separate random port if your application uses a different port for the management server.



[[testing.spring-boot-applications.detecting-web-app-type]]
== Detecting Web Application Type

If Spring MVC is available, a regular MVC-based application context is configured.
If you have only Spring WebFlux, we will detect that and configure a WebFlux-based application context instead.

If both are present, Spring MVC takes precedence.
If you want to test a reactive web application in this scenario, you must set the configprop:spring.main.web-application-type[] property:

include-code::MyWebFluxTests[]



[[testing.spring-boot-applications.detecting-configuration]]
== Detecting Test Configuration

If you are familiar with the Spring Test Framework, you may be used to using `@ContextConfiguration(classes=...)` in order to specify which Spring javadoc:org.springframework.context.annotation.Configuration[format=annotation] to load.
Alternatively, you might have often used nested javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes within your test.

When testing Spring Boot applications, this is often not required.
Spring Boot's `@*Test` annotations search for your primary configuration automatically whenever you do not explicitly define one.

The search algorithm works up from the package that contains the test until it finds a class annotated with javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] or javadoc:org.springframework.boot.SpringBootConfiguration[format=annotation].
As long as you xref:using/structuring-your-code.adoc[structured your code] in a sensible way, your main configuration is usually found.

[NOTE]
====
If you use a xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-tests[test annotation to test a more specific slice of your application], you should avoid adding configuration settings that are specific to a particular area on the xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.user-configuration-and-slicing[main method's application class].

The underlying component scan configuration of javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] defines exclude filters that are used to make sure slicing works as expected.
If you are using an explicit javadoc:org.springframework.context.annotation.ComponentScan[format=annotation] directive on your javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation]-annotated class, be aware that those filters will be disabled.
If you are using slicing, you should define them again.
====

If you want to customize the primary configuration, you can use a nested javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] class.
Unlike a nested javadoc:org.springframework.context.annotation.Configuration[format=annotation] class, which would be used instead of your application's primary configuration, a nested javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] class is used in addition to your application's primary configuration.

NOTE: Spring's test framework caches application contexts between tests.
Therefore, as long as your tests share the same configuration (no matter how it is discovered), the potentially time-consuming process of loading the context happens only once.



[[testing.spring-boot-applications.using-main]]
== Using the Test Configuration Main Method

Typically the test configuration discovered by javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] will be your main javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation].
In most well structured applications, this configuration class will also include the `main` method used to launch the application.

For example, the following is a very common code pattern for a typical Spring Boot application:

include-code::typical/MyApplication[]

In the example above, the `main` method doesn't do anything other than delegate to javadoc:org.springframework.boot.SpringApplication#run(java.lang.Class,java.lang.String...)[].
It is, however, possible to have a more complex `main` method that applies customizations before calling javadoc:org.springframework.boot.SpringApplication#run(java.lang.Class,java.lang.String...)[].

For example, here is an application that changes the banner mode and sets additional profiles:

include-code::custom/MyApplication[]

Since customizations in the `main` method can affect the resulting javadoc:org.springframework.context.ApplicationContext[], it's possible that you might also want to use the `main` method to create the javadoc:org.springframework.context.ApplicationContext[] used in your tests.
By default, javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] will not call your `main` method, and instead the class itself is used directly to create the javadoc:org.springframework.context.ApplicationContext[]

If you want to change this behavior, you can change the `useMainMethod` attribute of javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] to javadoc:org.springframework.boot.test.context.SpringBootTest$UseMainMethod#ALWAYS[] or javadoc:org.springframework.boot.test.context.SpringBootTest$UseMainMethod#WHEN_AVAILABLE[].
When set to `ALWAYS`, the test will fail if no `main` method can be found.
When set to `WHEN_AVAILABLE` the `main` method will be used if it is available, otherwise the standard loading mechanism will be used.

For example, the following test will invoke the `main` method of `MyApplication` in order to create the javadoc:org.springframework.context.ApplicationContext[].
If the main method sets additional profiles then those will be active when the javadoc:org.springframework.context.ApplicationContext[] starts.

include-code::always/MyApplicationTests[]



[[testing.spring-boot-applications.excluding-configuration]]
== Excluding Test Configuration

If your application uses component scanning (for example, if you use javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] or javadoc:org.springframework.context.annotation.ComponentScan[format=annotation]), you may find top-level configuration classes that you created only for specific tests accidentally get picked up everywhere.

As we xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.detecting-configuration[have seen earlier], javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] can be used on an inner class of a test to customize the primary configuration.
javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] can also be used on a top-level class. Doing so indicates that the class should not be picked up by scanning.
You can then import the class explicitly where it is required, as shown in the following example:

include-code::MyTests[]

NOTE: If you directly use javadoc:org.springframework.context.annotation.ComponentScan[format=annotation] (that is, not through javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation]) you need to register the javadoc:org.springframework.boot.context.TypeExcludeFilter[] with it.
See the javadoc:org.springframework.boot.context.TypeExcludeFilter[] API documentation for details.

NOTE: An imported javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] is processed earlier than an inner-class javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] and an imported javadoc:org.springframework.boot.test.context.TestConfiguration[format=annotation] will be processed before any configuration found through component scanning.
Generally speaking, this difference in ordering has no noticeable effect but it is something to be aware of if you're relying on bean overriding.



[[testing.spring-boot-applications.using-application-arguments]]
== Using Application Arguments

If your application expects xref:features/spring-application.adoc#features.spring-application.application-arguments[arguments], you can
have javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] inject them using the `args` attribute.

include-code::MyApplicationArgumentTests[]



[[testing.spring-boot-applications.with-mock-environment]]
== Testing With a Mock Environment

By default, javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] does not start the server but instead sets up a mock environment for testing web endpoints.

With Spring MVC, we can query our web endpoints using {url-spring-framework-docs}/testing/mockmvc.html[`MockMvc`].
Three integrations are available:

* The regular {url-spring-framework-docs}/testing/mockmvc/hamcrest.html[`MockMvc`] that uses Hamcrest.
* {url-spring-framework-docs}/testing/mockmvc/assertj.html[`MockMvcTester`] that wraps javadoc:org.springframework.test.web.servlet.MockMvc[] and uses AssertJ.
* {url-spring-framework-docs}/testing/webtestclient.html[`WebTestClient`] where javadoc:org.springframework.test.web.servlet.MockMvc[] is plugged in as the server to handle requests with.

The following example showcases the available integrations:

include-code::MyMockMvcTests[]

TIP: If you want to focus only on the web layer and not start a complete javadoc:org.springframework.context.ApplicationContext[], consider xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.spring-mvc-tests[using javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] instead].

With Spring WebFlux endpoints, you can use {url-spring-framework-docs}/testing/webtestclient.html[`WebTestClient`] as shown in the following example:

include-code::MyMockWebTestClientTests[]

[TIP]
====
Testing within a mocked environment is usually faster than running with a full servlet container.
However, since mocking occurs at the Spring MVC layer, code that relies on lower-level servlet container behavior cannot be directly tested with MockMvc.

For example, Spring Boot's error handling is based on the "`error page`" support provided by the servlet container.
This means that, whilst you can test your MVC layer throws and handles exceptions as expected, you cannot directly test that a specific xref:web/servlet.adoc#web.servlet.spring-mvc.error-handling.error-pages[custom error page] is rendered.
If you need to test these lower-level concerns, you can start a fully running server as described in the next section.
====



[[testing.spring-boot-applications.with-running-server]]
== Testing With a Running Server

If you need to start a full running server, we recommend that you use random ports.
If you use `@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)`, an available port is picked at random each time your test runs.

The javadoc:org.springframework.boot.test.web.server.LocalServerPort[format=annotation] annotation can be used to xref:how-to:webserver.adoc#howto.webserver.discover-port[inject the actual port used] into your test.
For convenience, tests that need to make REST calls to the started server can additionally autowire a {url-spring-framework-docs}/testing/webtestclient.html[`WebTestClient`], which resolves relative links to the running server and comes with a dedicated API for verifying responses, as shown in the following example:

include-code::MyRandomPortWebTestClientTests[]

TIP: javadoc:org.springframework.test.web.reactive.server.WebTestClient[] can also used with a xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.with-mock-environment[mock environment], removing the need for a running server, by annotating your test class with javadoc:org.springframework.boot.test.autoconfigure.web.reactive.AutoConfigureWebTestClient[format=annotation].

This setup requires `spring-webflux` on the classpath.
If you can not or will not add webflux, Spring Boot also provides a javadoc:org.springframework.boot.test.web.client.TestRestTemplate[] facility:

include-code::MyRandomPortTestRestTemplateTests[]



[[testing.spring-boot-applications.customizing-web-test-client]]
== Customizing WebTestClient

To customize the javadoc:org.springframework.test.web.reactive.server.WebTestClient[] bean, configure a javadoc:org.springframework.boot.test.web.reactive.server.WebTestClientBuilderCustomizer[] bean.
Any such beans are called with the javadoc:org.springframework.test.web.reactive.server.WebTestClient$Builder[] that is used to create the javadoc:org.springframework.test.web.reactive.server.WebTestClient[].



[[testing.spring-boot-applications.jmx]]
== Using JMX

As the test context framework caches context, JMX is disabled by default to prevent identical components to register on the same domain.
If such test needs access to an javadoc:javax.management.MBeanServer[], consider marking it dirty as well:

include-code::MyJmxTests[]



[[testing.spring-boot-applications.observations]]
== Using Observations

If you annotate xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-tests[a sliced test] with javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation], it auto-configures an javadoc:io.micrometer.observation.ObservationRegistry[].



[[testing.spring-boot-applications.metrics]]
== Using Metrics

Regardless of your classpath, meter registries, except the in-memory backed, are not auto-configured when using javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation].

If you need to export metrics to a different backend as part of an integration test, annotate it with javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation].

If you annotate xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-tests[a sliced test] with javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation], it auto-configures an in-memory javadoc:io.micrometer.core.instrument.MeterRegistry[].
Data exporting in sliced tests is not supported with the javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation] annotation.



[[testing.spring-boot-applications.tracing]]
== Using Tracing

Regardless of your classpath, tracing components which are reporting data are not auto-configured when using javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation].

If you need those components as part of an integration test, annotate the test with javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation].

If you have created your own reporting components (e.g. a custom javadoc:io.opentelemetry.sdk.trace.export.SpanExporter[] or `brave.handler.SpanHandler`) and you don't want them to be active in tests, you can use the javadoc:org.springframework.boot.actuate.autoconfigure.tracing.ConditionalOnEnabledTracing[format=annotation] annotation to disable them.

If you annotate xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-tests[a sliced test] with javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation], it auto-configures a no-op javadoc:io.micrometer.tracing.Tracer[].
Data exporting in sliced tests is not supported with the javadoc:org.springframework.boot.test.autoconfigure.actuate.observability.AutoConfigureObservability[format=annotation] annotation.



[[testing.spring-boot-applications.mocking-beans]]
== Mocking and Spying Beans

When running tests, it is sometimes necessary to mock certain components within your application context.
For example, you may have a facade over some remote service that is unavailable during development.
Mocking can also be useful when you want to simulate failures that might be hard to trigger in a real environment.

Spring Framework includes a javadoc:org.springframework.test.context.bean.override.mockito.MockitoBean[format=annotation] annotation that can be used to define a Mockito mock for a bean inside your javadoc:org.springframework.context.ApplicationContext[].
Additionally, javadoc:org.springframework.test.context.bean.override.mockito.MockitoSpyBean[format=annotation] can be used to define a Mockito spy.
Learn more about these features in the {url-spring-framework-docs}/testing/annotations/integration-spring/annotation-mockitobean.html[Spring Framework documentation].



[[testing.spring-boot-applications.autoconfigured-tests]]
== Auto-configured Tests

Spring Boot's auto-configuration system works well for applications but can sometimes be a little too much for tests.
It often helps to load only the parts of the configuration that are required to test a "`slice`" of your application.
For example, you might want to test that Spring MVC controllers are mapping URLs correctly, and you do not want to involve database calls in those tests, or you might want to test JPA entities, and you are not interested in the web layer when those tests run.

The `spring-boot-test-autoconfigure` module includes a number of annotations that can be used to automatically configure such "`slices`".
Each of them works in a similar way, providing a `@...Test` annotation that loads the javadoc:org.springframework.context.ApplicationContext[] and one or more `@AutoConfigure...` annotations that can be used to customize auto-configuration settings.

NOTE: Each slice restricts component scan to appropriate components and loads a very restricted set of auto-configuration classes.
If you need to exclude one of them, most `@...Test` annotations provide an `excludeAutoConfiguration` attribute.
Alternatively, you can use `@ImportAutoConfiguration#exclude`.

NOTE: Including multiple "`slices`" by using several `@...Test` annotations in one test is not supported.
If you need multiple "`slices`", pick one of the `@...Test` annotations and include the `@AutoConfigure...` annotations of the other "`slices`" by hand.

TIP: It is also possible to use the `@AutoConfigure...` annotations with the standard javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] annotation.
You can use this combination if you are not interested in "`slicing`" your application but you want some of the auto-configured test beans.



[[testing.spring-boot-applications.json-tests]]
== Auto-configured JSON Tests

To test that object JSON serialization and deserialization is working as expected, you can use the javadoc:org.springframework.boot.test.autoconfigure.json.JsonTest[format=annotation] annotation.
javadoc:org.springframework.boot.test.autoconfigure.json.JsonTest[format=annotation] auto-configures the available supported JSON mapper, which can be one of the following libraries:

* Jackson javadoc:com.fasterxml.jackson.databind.ObjectMapper[], any javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation] beans and any Jackson javadoc:com.fasterxml.jackson.databind.Module[]
* `Gson`
* `Jsonb`

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.json.JsonTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

If you need to configure elements of the auto-configuration, you can use the javadoc:org.springframework.boot.test.autoconfigure.json.AutoConfigureJsonTesters[format=annotation] annotation.

Spring Boot includes AssertJ-based helpers that work with the JSONAssert and JsonPath libraries to check that JSON appears as expected.
The javadoc:org.springframework.boot.test.json.JacksonTester[], javadoc:org.springframework.boot.test.json.GsonTester[], javadoc:org.springframework.boot.test.json.JsonbTester[], and javadoc:org.springframework.boot.test.json.BasicJsonTester[] classes can be used for Jackson, Gson, Jsonb, and Strings respectively.
Any helper fields on the test class can be javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation] when using javadoc:org.springframework.boot.test.autoconfigure.json.JsonTest[format=annotation].
The following example shows a test class for Jackson:

include-code::MyJsonTests[]

NOTE: JSON helper classes can also be used directly in standard unit tests.
To do so, call the `initFields` method of the helper in your javadoc:org.junit.jupiter.api.BeforeEach[format=annotation] method if you do not use javadoc:org.springframework.boot.test.autoconfigure.json.JsonTest[format=annotation].

If you use Spring Boot's AssertJ-based helpers to assert on a number value at a given JSON path, you might not be able to use `isEqualTo` depending on the type.
Instead, you can use AssertJ's `satisfies` to assert that the value matches the given condition.
For instance, the following example asserts that the actual number is a float value close to `0.15` within an offset of `0.01`.

include-code::MyJsonAssertJTests[tag=*]



[[testing.spring-boot-applications.spring-mvc-tests]]
== Auto-configured Spring MVC Tests

To test whether Spring MVC controllers are working as expected, use the javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] annotation.
javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] auto-configures the Spring MVC infrastructure and limits scanned beans to javadoc:org.springframework.stereotype.Controller[format=annotation], javadoc:org.springframework.web.bind.annotation.ControllerAdvice[format=annotation], javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation], javadoc:org.springframework.core.convert.converter.Converter[], javadoc:org.springframework.core.convert.converter.GenericConverter[], javadoc:jakarta.servlet.Filter[], javadoc:org.springframework.web.servlet.HandlerInterceptor[], javadoc:org.springframework.web.servlet.config.annotation.WebMvcConfigurer[], javadoc:org.springframework.boot.autoconfigure.web.servlet.WebMvcRegistrations[], and javadoc:org.springframework.web.method.support.HandlerMethodArgumentResolver[].
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

TIP: If you need to register extra components, such as the Jackson javadoc:com.fasterxml.jackson.databind.Module[], you can import additional configuration classes by using javadoc:org.springframework.context.annotation.Import[format=annotation] on your test.

Often, javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] is limited to a single controller and is used in combination with javadoc:org.springframework.boot.test.mock.mockito.MockBean[format=annotation] to provide mock implementations for required collaborators.

javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] also auto-configures javadoc:org.springframework.test.web.servlet.MockMvc[].
Mock MVC offers a powerful way to quickly test MVC controllers without needing to start a full HTTP server.
If AssertJ is available, the AssertJ support provided by javadoc:org.springframework.test.web.servlet.assertj.MockMvcTester[] is auto-configured as well.

TIP: You can also auto-configure javadoc:org.springframework.test.web.servlet.MockMvc[] and javadoc:org.springframework.test.web.servlet.assertj.MockMvcTester[] in a non-`@WebMvcTest` (such as javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation]) by annotating it with javadoc:org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc[format=annotation].
The following example uses javadoc:org.springframework.test.web.servlet.assertj.MockMvcTester[]:

include-code::MyControllerTests[]

TIP: If you need to configure elements of the auto-configuration (for example, when servlet filters should be applied) you can use attributes in the javadoc:org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc[format=annotation] annotation.

If you use HtmlUnit and Selenium, auto-configuration also provides an HtmlUnit javadoc:org.springframework.web.reactive.function.client.WebClient[] bean and/or a Selenium javadoc:org.openqa.selenium.WebDriver[] bean.
The following example uses HtmlUnit:

include-code::MyHtmlUnitTests[]

NOTE: By default, Spring Boot puts javadoc:org.openqa.selenium.WebDriver[] beans in a special "`scope`" to ensure that the driver exits after each test and that a new instance is injected.
If you do not want this behavior, you can add `@Scope(ConfigurableBeanFactory.SCOPE_SINGLETON)` to your javadoc:org.openqa.selenium.WebDriver[] javadoc:org.springframework.context.annotation.Bean[format=annotation] definition.

WARNING: The `webDriver` scope created by Spring Boot will replace any user defined scope of the same name.
If you define your own `webDriver` scope you may find it stops working when you use javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation].

If you have Spring Security on the classpath, javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation] will also scan javadoc:org.springframework.security.config.annotation.web.WebSecurityConfigurer[] beans.
Instead of disabling security completely for such tests, you can use Spring Security's test support.
More details on how to use Spring Security's javadoc:org.springframework.test.web.servlet.MockMvc[] support can be found in this xref:how-to:testing.adoc#howto.testing.with-spring-security[] "`How-to Guides`" section.

TIP: Sometimes writing Spring MVC tests is not enough; Spring Boot can help you run xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.with-running-server[full end-to-end tests with an actual server].



[[testing.spring-boot-applications.spring-webflux-tests]]
== Auto-configured Spring WebFlux Tests

To test that {url-spring-framework-docs}/web-reactive.html[Spring WebFlux] controllers are working as expected, you can use the javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] annotation.
javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] auto-configures the Spring WebFlux infrastructure and limits scanned beans to javadoc:org.springframework.stereotype.Controller[format=annotation], javadoc:org.springframework.web.bind.annotation.ControllerAdvice[format=annotation], javadoc:org.springframework.boot.jackson.JsonComponent[format=annotation], javadoc:org.springframework.core.convert.converter.Converter[], javadoc:org.springframework.core.convert.converter.GenericConverter[] and javadoc:org.springframework.web.reactive.config.WebFluxConfigurer[].
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

TIP: If you need to register extra components, such as Jackson javadoc:com.fasterxml.jackson.databind.Module[], you can import additional configuration classes using javadoc:org.springframework.context.annotation.Import[format=annotation] on your test.

Often, javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] is limited to a single controller and used in combination with the javadoc:org.springframework.boot.test.mock.mockito.MockBean[format=annotation] annotation to provide mock implementations for required collaborators.

javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] also auto-configures {url-spring-framework-docs}/testing/webtestclient.html[`WebTestClient`], which offers a powerful way to quickly test WebFlux controllers without needing to start a full HTTP server.

TIP: You can also auto-configure javadoc:org.springframework.test.web.reactive.server.WebTestClient[] in a non-`@WebFluxTest` (such as javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation]) by annotating it with javadoc:org.springframework.boot.test.autoconfigure.web.reactive.AutoConfigureWebTestClient[format=annotation].
The following example shows a class that uses both javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] and a javadoc:org.springframework.test.web.reactive.server.WebTestClient[]:

include-code::MyControllerTests[]

TIP: This setup is only supported by WebFlux applications as using javadoc:org.springframework.test.web.reactive.server.WebTestClient[] in a mocked web application only works with WebFlux at the moment.

NOTE: javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] cannot detect routes registered through the functional web framework.
For testing javadoc:org.springframework.web.reactive.function.server.RouterFunction[] beans in the context, consider importing your javadoc:org.springframework.web.reactive.function.server.RouterFunction[] yourself by using javadoc:org.springframework.context.annotation.Import[format=annotation] or by using javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation].

NOTE: javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] cannot detect custom security configuration registered as a javadoc:org.springframework.context.annotation.Bean[format=annotation] of type javadoc:org.springframework.security.web.server.SecurityWebFilterChain[].
To include that in your test, you will need to import the configuration that registers the bean by using javadoc:org.springframework.context.annotation.Import[format=annotation] or by using javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation].

TIP: Sometimes writing Spring WebFlux tests is not enough; Spring Boot can help you run xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.with-running-server[full end-to-end tests with an actual server].



[[testing.spring-boot-applications.spring-graphql-tests]]
== Auto-configured Spring GraphQL Tests

Spring GraphQL offers a dedicated testing support module; you'll need to add it to your project:

.Maven
[source,xml]
----
<dependencies>
	<dependency>
		<groupId>org.springframework.graphql</groupId>
		<artifactId>spring-graphql-test</artifactId>
		<scope>test</scope>
	</dependency>
	<!-- Unless already present in the compile scope -->
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-webflux</artifactId>
		<scope>test</scope>
	</dependency>
</dependencies>
----

.Gradle
[source,gradle]
----
dependencies {
	testImplementation("org.springframework.graphql:spring-graphql-test")
	// Unless already present in the implementation configuration
	testImplementation("org.springframework.boot:spring-boot-starter-webflux")
}
----

This testing module ships the {url-spring-graphql-docs}/testing.html#testing.graphqltester[GraphQlTester].
The tester is heavily used in test, so be sure to become familiar with using it.
There are javadoc:org.springframework.graphql.test.tester.GraphQlTester[] variants and Spring Boot will auto-configure them depending on the type of tests:

* the javadoc:org.springframework.graphql.test.tester.ExecutionGraphQlServiceTester[] performs tests on the server side, without a client nor a transport
* the javadoc:org.springframework.graphql.test.tester.HttpGraphQlTester[] performs tests with a client that connects to a server, with or without a live server

Spring Boot helps you to test your {url-spring-graphql-docs}/controllers.html[Spring GraphQL Controllers] with the javadoc:org.springframework.boot.test.autoconfigure.graphql.GraphQlTest[format=annotation] annotation.
javadoc:org.springframework.boot.test.autoconfigure.graphql.GraphQlTest[format=annotation] auto-configures the Spring GraphQL infrastructure, without any transport nor server being involved.
This limits scanned beans to javadoc:org.springframework.stereotype.Controller[format=annotation], javadoc:org.springframework.graphql.execution.RuntimeWiringConfigurer[], javadoc:org.springframework.boot.jackson.JsonComponent[], javadoc:org.springframework.core.convert.converter.Converter[], javadoc:org.springframework.core.convert.converter.GenericConverter[], javadoc:org.springframework.graphql.execution.DataFetcherExceptionResolver[], javadoc:graphql.execution.instrumentation.Instrumentation[] and javadoc:org.springframework.boot.autoconfigure.graphql.GraphQlSourceBuilderCustomizer[].
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.graphql.GraphQlTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.graphql.GraphQlTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

Often, javadoc:org.springframework.boot.test.autoconfigure.graphql.GraphQlTest[format=annotation] is limited to a set of controllers and used in combination with the javadoc:org.springframework.boot.test.mock.mockito.MockBean[format=annotation] annotation to provide mock implementations for required collaborators.

include-code::GreetingControllerTests[]

javadoc:org.springframework.boot.test.context.SpringBootTest[format=annotation] tests are full integration tests and involve the entire application.
When using a random or defined port, a live server is configured and an javadoc:org.springframework.graphql.test.tester.HttpGraphQlTester[] bean is contributed automatically so you can use it to test your server.
When a MOCK environment is configured, you can also request an javadoc:org.springframework.graphql.test.tester.HttpGraphQlTester[] bean by annotating your test class with javadoc:org.springframework.boot.test.autoconfigure.graphql.tester.AutoConfigureHttpGraphQlTester[format=annotation]:

include-code::GraphQlIntegrationTests[]



[[testing.spring-boot-applications.autoconfigured-spring-data-cassandra]]
== Auto-configured Data Cassandra Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.cassandra.DataCassandraTest[format=annotation] to test Cassandra applications.
By default, it configures a javadoc:org.springframework.data.cassandra.core.CassandraTemplate[], scans for javadoc:org.springframework.data.cassandra.core.mapping.Table[format=annotation] classes, and configures Spring Data Cassandra repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.cassandra.DataCassandraTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using Cassandra with Spring Boot, see xref:data/nosql.adoc#data.nosql.cassandra[].)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.cassandra.DataCassandraTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows a typical setup for using Cassandra tests in Spring Boot:

include-code::MyDataCassandraTests[]



[[testing.spring-boot-applications.autoconfigured-spring-data-couchbase]]
== Auto-configured Data Couchbase Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.couchbase.DataCouchbaseTest[format=annotation] to test Couchbase applications.
By default, it configures a javadoc:org.springframework.data.couchbase.core.CouchbaseTemplate[] or javadoc:org.springframework.data.couchbase.core.ReactiveCouchbaseTemplate[], scans for javadoc:org.springframework.data.couchbase.core.mapping.Document[format=annotation] classes, and configures Spring Data Couchbase repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.couchbase.DataCouchbaseTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using Couchbase with Spring Boot, see xref:data/nosql.adoc#data.nosql.couchbase[], earlier in this chapter.)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.couchbase.DataCouchbaseTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows a typical setup for using Couchbase tests in Spring Boot:

include-code::MyDataCouchbaseTests[]



[[testing.spring-boot-applications.autoconfigured-spring-data-elasticsearch]]
== Auto-configured Data Elasticsearch Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.elasticsearch.DataElasticsearchTest[format=annotation] to test Elasticsearch applications.
By default, it configures an javadoc:org.springframework.data.elasticsearch.client.elc.ElasticsearchTemplate[], scans for javadoc:org.springframework.data.elasticsearch.annotations.Document[format=annotation] classes, and configures Spring Data Elasticsearch repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.elasticsearch.DataElasticsearchTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using Elasticsearch with Spring Boot, see xref:data/nosql.adoc#data.nosql.elasticsearch[], earlier in this chapter.)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.elasticsearch.DataElasticsearchTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows a typical setup for using Elasticsearch tests in Spring Boot:

include-code::MyDataElasticsearchTests[]



[[testing.spring-boot-applications.autoconfigured-spring-data-jpa]]
== Auto-configured Data JPA Tests

You can use the javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation] annotation to test JPA applications.
By default, it scans for javadoc:jakarta.persistence.Entity[format=annotation] classes and configures Spring Data JPA repositories.
If an embedded database is available on the classpath, it configures one as well.
SQL queries are logged by default by setting the `spring.jpa.show-sql` property to `true`.
This can be disabled using the `showSql` attribute of the annotation.

Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

By default, data JPA tests are transactional and roll back at the end of each test.
See the {url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
If that is not what you want, you can disable transaction management for a test or for the whole class as follows:

include-code::MyNonTransactionalTests[]

Data JPA tests may also inject a javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager[] bean, which provides an alternative to the standard JPA javadoc:jakarta.persistence.EntityManager[] that is specifically designed for tests.

TIP: javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager[] can also be auto-configured to any of your Spring-based test class by adding javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.AutoConfigureTestEntityManager[format=annotation].
When doing so, make sure that your test is running in a transaction, for instance by adding  javadoc:org.springframework.transaction.annotation.Transactional[format=annotation] on your test class or method.

A javadoc:org.springframework.jdbc.core.JdbcTemplate[] is also available if you need that.
The following example shows the javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation] annotation in use:

include-code::withoutdb/MyRepositoryTests[]

In-memory embedded databases generally work well for tests, since they are fast and do not require any installation.
If, however, you prefer to run tests against a real database you can use the javadoc:org.springframework.boot.test.autoconfigure.jdbc.AutoConfigureTestDatabase[format=annotation] annotation, as shown in the following example:

include-code::withdb/MyRepositoryTests[]



[[testing.spring-boot-applications.autoconfigured-jdbc]]
== Auto-configured JDBC Tests

javadoc:org.springframework.boot.test.autoconfigure.jdbc.JdbcTest[format=annotation] is similar to javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation] but is for tests that only require a javadoc:javax.sql.DataSource[] and do not use Spring Data JDBC.
By default, it configures an in-memory embedded database and a javadoc:org.springframework.jdbc.core.JdbcTemplate[].
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.jdbc.JdbcTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.jdbc.JdbcTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

By default, JDBC tests are transactional and roll back at the end of each test.
See the {url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
If that is not what you want, you can disable transaction management for a test or for the whole class, as follows:

include-code::MyTransactionalTests[]

If you prefer your test to run against a real database, you can use the javadoc:org.springframework.boot.test.autoconfigure.jdbc.AutoConfigureTestDatabase[format=annotation] annotation in the same way as for javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation].
(See xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-spring-data-jpa[].)



[[testing.spring-boot-applications.autoconfigured-spring-data-jdbc]]
== Auto-configured Data JDBC Tests

javadoc:org.springframework.boot.test.autoconfigure.data.jdbc.DataJdbcTest[format=annotation] is similar to javadoc:org.springframework.boot.test.autoconfigure.jdbc.JdbcTest[format=annotation] but is for tests that use Spring Data JDBC repositories.
By default, it configures an in-memory embedded database, a javadoc:org.springframework.jdbc.core.JdbcTemplate[], and Spring Data JDBC repositories.
Only javadoc:org.springframework.data.jdbc.repository.config.AbstractJdbcConfiguration[] subclasses are scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.jdbc.DataJdbcTest[format=annotation] annotation is used, regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.jdbc.DataJdbcTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

By default, Data JDBC tests are transactional and roll back at the end of each test.
See the {url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
If that is not what you want, you can disable transaction management for a test or for the whole test class as xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-jdbc[shown in the JDBC example].

If you prefer your test to run against a real database, you can use the javadoc:org.springframework.boot.test.autoconfigure.jdbc.AutoConfigureTestDatabase[format=annotation] annotation in the same way as for javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation].
(See xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-spring-data-jpa[].)



[[testing.spring-boot-applications.autoconfigured-spring-data-r2dbc]]
== Auto-configured Data R2DBC Tests

javadoc:org.springframework.boot.test.autoconfigure.data.r2dbc.DataR2dbcTest[format=annotation] is similar to javadoc:org.springframework.boot.test.autoconfigure.data.jdbc.DataJdbcTest[format=annotation] but is for tests that use Spring Data R2DBC repositories.
By default, it configures an in-memory embedded database, an javadoc:org.springframework.data.r2dbc.core.R2dbcEntityTemplate[], and Spring Data R2DBC repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.r2dbc.DataR2dbcTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.r2dbc.DataR2dbcTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

By default, Data R2DBC tests are not transactional.

If you prefer your test to run against a real database, you can use the javadoc:org.springframework.boot.test.autoconfigure.jdbc.AutoConfigureTestDatabase[format=annotation] annotation in the same way as for javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation].
(See xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-spring-data-jpa[].)



[[testing.spring-boot-applications.autoconfigured-jooq]]
== Auto-configured jOOQ Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.jooq.JooqTest[format=annotation] in a similar fashion as javadoc:org.springframework.boot.test.autoconfigure.jdbc.JdbcTest[format=annotation] but for jOOQ-related tests.
As jOOQ relies heavily on a Java-based schema that corresponds with the database schema, the existing javadoc:javax.sql.DataSource[] is used.
If you want to replace it with an in-memory database, you can use javadoc:org.springframework.boot.test.autoconfigure.jdbc.AutoConfigureTestDatabase[format=annotation] to override those settings.
(For more about using jOOQ with Spring Boot, see xref:data/sql.adoc#data.sql.jooq[].)
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.jooq.JooqTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configurations that are enabled by javadoc:org.springframework.boot.test.autoconfigure.jooq.JooqTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

javadoc:org.springframework.boot.test.autoconfigure.jooq.JooqTest[format=annotation] configures a javadoc:org.jooq.DSLContext[].
The following example shows the javadoc:org.springframework.boot.test.autoconfigure.jooq.JooqTest[format=annotation] annotation in use:

include-code::MyJooqTests[]

JOOQ tests are transactional and roll back at the end of each test by default.
If that is not what you want, you can disable transaction management for a test or for the whole test class as xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.autoconfigured-jdbc[shown in the JDBC example].



[[testing.spring-boot-applications.autoconfigured-spring-data-mongodb]]
== Auto-configured Data MongoDB Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.mongo.DataMongoTest[format=annotation] to test MongoDB applications.
By default, it configures a javadoc:org.springframework.data.mongodb.core.MongoTemplate[], scans for javadoc:org.springframework.data.mongodb.core.mapping.Document[format=annotation] classes, and configures Spring Data MongoDB repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.mongo.DataMongoTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using MongoDB with Spring Boot, see xref:data/nosql.adoc#data.nosql.mongodb[].)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.mongo.DataMongoTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following class shows the javadoc:org.springframework.boot.test.autoconfigure.data.mongo.DataMongoTest[format=annotation] annotation in use:

include-code::MyDataMongoDbTests[]



[[testing.spring-boot-applications.autoconfigured-spring-data-neo4j]]
== Auto-configured Data Neo4j Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.neo4j.DataNeo4jTest[format=annotation] to test Neo4j applications.
By default, it scans for javadoc:org.springframework.data.neo4j.core.schema.Node[format=annotation] classes, and configures Spring Data Neo4j repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.neo4j.DataNeo4jTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using Neo4J with Spring Boot, see xref:data/nosql.adoc#data.nosql.neo4j[].)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.neo4j.DataNeo4jTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows a typical setup for using Neo4J tests in Spring Boot:

include-code::propagation/MyDataNeo4jTests[]

By default, Data Neo4j tests are transactional and roll back at the end of each test.
See the {url-spring-framework-docs}/testing/testcontext-framework/tx.html#testcontext-tx-enabling-transactions[relevant section] in the Spring Framework Reference Documentation for more details.
If that is not what you want, you can disable transaction management for a test or for the whole class, as follows:

include-code::nopropagation/MyDataNeo4jTests[]

NOTE: Transactional tests are not supported with reactive access.
If you are using this style, you must configure javadoc:org.springframework.boot.test.autoconfigure.data.neo4j.DataNeo4jTest[format=annotation] tests as described above.



[[testing.spring-boot-applications.autoconfigured-spring-data-redis]]
== Auto-configured Data Redis Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.redis.DataRedisTest[format=annotation] to test Redis applications.
By default, it scans for javadoc:org.springframework.data.redis.core.RedisHash[format=annotation] classes and configures Spring Data Redis repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.redis.DataRedisTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using Redis with Spring Boot, see xref:data/nosql.adoc#data.nosql.redis[].)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.redis.DataRedisTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows the javadoc:org.springframework.boot.test.autoconfigure.data.redis.DataRedisTest[format=annotation] annotation in use:

include-code::MyDataRedisTests[]



[[testing.spring-boot-applications.autoconfigured-spring-data-ldap]]
== Auto-configured Data LDAP Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.data.ldap.DataLdapTest[format=annotation] to test LDAP applications.
By default, it configures an in-memory embedded LDAP (if available), configures an javadoc:org.springframework.ldap.core.LdapTemplate[], scans for javadoc:org.springframework.ldap.odm.annotations.Entry[format=annotation] classes, and configures Spring Data LDAP repositories.
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.data.ldap.DataLdapTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.
(For more about using LDAP with Spring Boot, see xref:data/nosql.adoc#data.nosql.ldap[].)

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.data.ldap.DataLdapTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows the javadoc:org.springframework.boot.test.autoconfigure.data.ldap.DataLdapTest[format=annotation] annotation in use:

include-code::inmemory/MyDataLdapTests[]

In-memory embedded LDAP generally works well for tests, since it is fast and does not require any developer installation.
If, however, you prefer to run tests against a real LDAP server, you should exclude the embedded LDAP auto-configuration, as shown in the following example:

include-code::server/MyDataLdapTests[]



[[testing.spring-boot-applications.autoconfigured-rest-client]]
== Auto-configured REST Clients

You can use the javadoc:org.springframework.boot.test.autoconfigure.web.client.RestClientTest[format=annotation] annotation to test REST clients.
By default, it auto-configures Jackson, GSON, and Jsonb support, configures a javadoc:org.springframework.boot.web.client.RestTemplateBuilder[] and a javadoc:org.springframework.web.client.RestClient$Builder[], and adds support for javadoc:org.springframework.test.web.client.MockRestServiceServer[].
Regular javadoc:org.springframework.stereotype.Component[format=annotation] and javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans are not scanned when the javadoc:org.springframework.boot.test.autoconfigure.web.client.RestClientTest[format=annotation] annotation is used.
javadoc:org.springframework.boot.context.properties.EnableConfigurationProperties[format=annotation] can be used to include javadoc:org.springframework.boot.context.properties.ConfigurationProperties[format=annotation] beans.

TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.web.client.RestClientTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The specific beans that you want to test should be specified by using the `value` or `components` attribute of javadoc:org.springframework.boot.test.autoconfigure.web.client.RestClientTest[format=annotation].

When using a javadoc:org.springframework.boot.web.client.RestTemplateBuilder[] in the beans under test and `RestTemplateBuilder.rootUri(String rootUri)` has been called when building the javadoc:org.springframework.web.client.RestTemplate[], then the root URI should be omitted from the javadoc:org.springframework.test.web.client.MockRestServiceServer[] expectations as shown in the following example:

include-code::MyRestTemplateServiceTests[]

When using a javadoc:org.springframework.web.client.RestClient$Builder[] in the beans under test, or when using a javadoc:org.springframework.boot.web.client.RestTemplateBuilder[] without calling `rootUri(String rootURI)`, the full URI must be used in the javadoc:org.springframework.test.web.client.MockRestServiceServer[] expectations as shown in the following example:

include-code::MyRestClientServiceTests[]



[[testing.spring-boot-applications.autoconfigured-spring-restdocs]]
== Auto-configured Spring REST Docs Tests

You can use the javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation] annotation to use {url-spring-restdocs-site}[Spring REST Docs] in your tests with Mock MVC, REST Assured, or WebTestClient.
It removes the need for the JUnit extension in Spring REST Docs.

javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation] can be used to override the default output directory (`target/generated-snippets` if you are using Maven or `build/generated-snippets` if you are using Gradle).
It can also be used to configure the host, scheme, and port that appears in any documented URIs.



[[testing.spring-boot-applications.autoconfigured-spring-restdocs.with-mock-mvc]]
=== Auto-configured Spring REST Docs Tests With Mock MVC

javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation] customizes the javadoc:org.springframework.test.web.servlet.MockMvc[] bean to use Spring REST Docs when testing servlet-based web applications.
You can inject it by using javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation] and use it in your tests as you normally would when using Mock MVC and Spring REST Docs, as shown in the following example:

include-code::hamcrest/MyUserDocumentationTests[]

If you prefer to use the AssertJ integration, javadoc:org.springframework.test.web.servlet.assertj.MockMvcTester[] is available as well, as shown in the following example:

include-code::assertj/MyUserDocumentationTests[]

Both reuses the same javadoc:org.springframework.test.web.servlet.MockMvc[] instance behind the scenes so any configuration to it applies to both.

If you require more control over Spring REST Docs configuration than offered by the attributes of javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation], you can use a javadoc:org.springframework.boot.test.autoconfigure.restdocs.RestDocsMockMvcConfigurationCustomizer[] bean, as shown in the following example:

include-code::MyRestDocsConfiguration[]

If you want to make use of Spring REST Docs support for a parameterized output directory, you can create a javadoc:org.springframework.restdocs.mockmvc.RestDocumentationResultHandler[] bean.
The auto-configuration calls `alwaysDo` with this result handler, thereby causing each javadoc:org.springframework.test.web.servlet.MockMvc[] call to automatically generate the default snippets.
The following example shows a javadoc:org.springframework.restdocs.mockmvc.RestDocumentationResultHandler[] being defined:

include-code::MyResultHandlerConfiguration[]



[[testing.spring-boot-applications.autoconfigured-spring-restdocs.with-web-test-client]]
=== Auto-configured Spring REST Docs Tests With WebTestClient

javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation] can also be used with javadoc:org.springframework.test.web.reactive.server.WebTestClient[] when testing reactive web applications.
You can inject it by using javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation] and use it in your tests as you normally would when using javadoc:org.springframework.boot.test.autoconfigure.web.reactive.WebFluxTest[format=annotation] and Spring REST Docs, as shown in the following example:

include-code::MyUsersDocumentationTests[]

If you require more control over Spring REST Docs configuration than offered by the attributes of javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation], you can use a javadoc:org.springframework.boot.test.autoconfigure.restdocs.RestDocsWebTestClientConfigurationCustomizer[] bean, as shown in the following example:

include-code::MyRestDocsConfiguration[]

If you want to make use of Spring REST Docs support for a parameterized output directory, you can use a javadoc:org.springframework.boot.test.web.reactive.server.WebTestClientBuilderCustomizer[] to configure a consumer for every entity exchange result.
The following example shows such a javadoc:org.springframework.boot.test.web.reactive.server.WebTestClientBuilderCustomizer[] being defined:

include-code::MyWebTestClientBuilderCustomizerConfiguration[]



[[testing.spring-boot-applications.autoconfigured-spring-restdocs.with-rest-assured]]
=== Auto-configured Spring REST Docs Tests With REST Assured

javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation] makes a javadoc:io.restassured.specification.RequestSpecification[] bean, preconfigured to use Spring REST Docs, available to your tests.
You can inject it by using javadoc:org.springframework.beans.factory.annotation.Autowired[format=annotation] and use it in your tests as you normally would when using REST Assured and Spring REST Docs, as shown in the following example:

include-code::MyUserDocumentationTests[]

If you require more control over Spring REST Docs configuration than offered by the attributes of javadoc:org.springframework.boot.test.autoconfigure.restdocs.AutoConfigureRestDocs[format=annotation], a javadoc:org.springframework.boot.test.autoconfigure.restdocs.RestDocsRestAssuredConfigurationCustomizer[] bean can be used, as shown in the following example:

include-code::MyRestDocsConfiguration[]



[[testing.spring-boot-applications.autoconfigured-webservices]]
== Auto-configured Spring Web Services Tests



[[testing.spring-boot-applications.autoconfigured-webservices.client]]
=== Auto-configured Spring Web Services Client Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.webservices.client.WebServiceClientTest[format=annotation] to test applications that call web services using the Spring Web Services project.
By default, it configures a javadoc:org.springframework.ws.test.client.MockWebServiceServer[] bean and automatically customizes your javadoc:org.springframework.boot.webservices.client.WebServiceTemplateBuilder[].
(For more about using Web Services with Spring Boot, see xref:io/webservices.adoc[].)


TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.webservices.client.WebServiceClientTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows the javadoc:org.springframework.boot.test.autoconfigure.webservices.client.WebServiceClientTest[format=annotation] annotation in use:

include-code::MyWebServiceClientTests[]



[[testing.spring-boot-applications.autoconfigured-webservices.server]]
=== Auto-configured Spring Web Services Server Tests

You can use javadoc:org.springframework.boot.test.autoconfigure.webservices.server.WebServiceServerTest[format=annotation] to test applications that implement web services using the Spring Web Services project.
By default, it configures a javadoc:org.springframework.ws.test.server.MockWebServiceClient[] bean that can be used to call your web service endpoints.
(For more about using Web Services with Spring Boot, see xref:io/webservices.adoc[].)


TIP: A list of the auto-configuration settings that are enabled by javadoc:org.springframework.boot.test.autoconfigure.webservices.server.WebServiceServerTest[format=annotation] can be xref:appendix:test-auto-configuration/index.adoc[found in the appendix].

The following example shows the javadoc:org.springframework.boot.test.autoconfigure.webservices.server.WebServiceServerTest[format=annotation] annotation in use:

include-code::MyWebServiceServerTests[]



[[testing.spring-boot-applications.additional-autoconfiguration-and-slicing]]
== Additional Auto-configuration and Slicing

Each slice provides one or more `@AutoConfigure...` annotations that namely defines the auto-configurations that should be included as part of a slice.
Additional auto-configurations can be added on a test-by-test basis by creating a custom `@AutoConfigure...` annotation or by adding javadoc:org.springframework.boot.autoconfigure.ImportAutoConfiguration[format=annotation] to the test as shown in the following example:

include-code::MyJdbcTests[]

NOTE: Make sure to not use the regular javadoc:org.springframework.context.annotation.Import[format=annotation] annotation to import auto-configurations as they are handled in a specific way by Spring Boot.

Alternatively, additional auto-configurations can be added for any use of a slice annotation by registering them in a file stored in `META-INF/spring` as shown in the following example:

.META-INF/spring/org.springframework.boot.test.autoconfigure.jdbc.JdbcTest.imports
[source]
----
com.example.IntegrationAutoConfiguration
----

In this example, the `+com.example.IntegrationAutoConfiguration+` is enabled on every test annotated with javadoc:org.springframework.boot.test.autoconfigure.jdbc.JdbcTest[format=annotation].

TIP: You can use comments with `#` in this file.

TIP: A slice or `@AutoConfigure...` annotation can be customized this way as long as it is meta-annotated with javadoc:org.springframework.boot.autoconfigure.ImportAutoConfiguration[format=annotation].



[[testing.spring-boot-applications.user-configuration-and-slicing]]
== User Configuration and Slicing

If you xref:using/structuring-your-code.adoc[structure your code] in a sensible way, your javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] class is xref:testing/spring-boot-applications.adoc#testing.spring-boot-applications.detecting-configuration[used by default] as the configuration of your tests.

It then becomes important not to litter the application's main class with configuration settings that are specific to a particular area of its functionality.

Assume that you are using Spring Data MongoDB, you rely on the auto-configuration for it, and you have enabled auditing.
You could define your javadoc:org.springframework.boot.autoconfigure.SpringBootApplication[format=annotation] as follows:

include-code::MyApplication[]

Because this class is the source configuration for the test, any slice test actually tries to enable Mongo auditing, which is definitely not what you want to do.
A recommended approach is to move that area-specific configuration to a separate javadoc:org.springframework.context.annotation.Configuration[format=annotation] class at the same level as your application, as shown in the following example:

include-code::MyMongoConfiguration[]

NOTE: Depending on the complexity of your application, you may either have a single javadoc:org.springframework.context.annotation.Configuration[format=annotation] class for your customizations or one class per domain area.
The latter approach lets you enable it in one of your tests, if necessary, with the javadoc:org.springframework.context.annotation.Import[format=annotation] annotation.
See xref:how-to:testing.adoc#howto.testing.slice-tests[this how-to section] for more details on when you might want to enable specific javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes for slice tests.

Test slices exclude javadoc:org.springframework.context.annotation.Configuration[format=annotation] classes from scanning.
For example, for a javadoc:org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest[format=annotation], the following configuration will not include the given javadoc:org.springframework.web.servlet.config.annotation.WebMvcConfigurer[] bean in the application context loaded by the test slice:

include-code::MyWebConfiguration[]

The configuration below will, however, cause the custom javadoc:org.springframework.web.servlet.config.annotation.WebMvcConfigurer[] to be loaded by the test slice.

include-code::MyWebMvcConfigurer[]

Another source of confusion is classpath scanning.
Assume that, while you structured your code in a sensible way, you need to scan an additional package.
Your application may resemble the following code:

include-code::scan/MyApplication[]

Doing so effectively overrides the default component scan directive with the side effect of scanning those two packages regardless of the slice that you chose.
For instance, a javadoc:org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest[format=annotation] seems to suddenly scan components and user configurations of your application.
Again, moving the custom directive to a separate class is a good way to fix this issue.

TIP: If this is not an option for you, you can create a javadoc:org.springframework.boot.SpringBootConfiguration[format=annotation] somewhere in the hierarchy of your test so that it is used instead.
Alternatively, you can specify a source for your test, which disables the behavior of finding a default one.



[[testing.spring-boot-applications.spock]]
== Using Spock to Test Spring Boot Applications

Spock 2.2 or later can be used to test a Spring Boot application.
To do so, add a dependency on a `-groovy-4.0` version of Spock's `spock-spring` module to your application's build.
`spock-spring` integrates Spring's test framework into Spock.
See https://spockframework.org/spock/docs/2.2-M1/modules.html#_spring_module[the documentation for Spock's Spring module] for further details.
