<commit_before>[[features.testing]]
== Testing
Spring Boot provides a number of utilities and annotations to help when testing your application.
Test support is provided by two modules: `spring-boot-test` contains core items, and `spring-boot-test-autoconfigure` supports auto-configuration for tests.

Most developers use the `spring-boot-starter-test` "`Starter`", which imports both Spring Boot test modules as well as JUnit Jupiter, AssertJ, Hamcrest, and a number of other useful libraries.

[TIP]
====
If you have tests that use JUnit 4, JUnit 5's vintage engine can be used to run them.
To use the vintage engine, add a dependency on `junit-vintage-engine`, as shown in the following example:

[source,xml,indent=0,subs="verbatim"]
----
	<dependency>
		<groupId>org.junit.vintage</groupId>
		<artifactId>junit-vintage-engine</artifactId>
		<scope>test</scope>
		<exclusions>
			<exclusion>
				<groupId>org.hamcrest</groupId>
				<artifactId>hamcrest-core</artifactId>
			</exclusion>
		</exclusions>
	</dependency>
----
====

`hamcrest-core` is excluded in favor of `org.hamcrest:hamcrest` that is part of `spring-boot-starter-test`.



[[features.testing.test-scope-dependencies]]
=== Test Scope Dependencies
The `spring-boot-starter-test` "`Starter`" (in the `test` `scope`) contains the following provided libraries:

* https://junit.org/junit5/[JUnit 5]: The de-facto standard for unit testing Java applications.
* {spring-framework-docs}/testing.html#integration-testing[Spring Test] & Spring Boot Test: Utilities and integration test support for Spring Boot applications.
* https://assertj.github.io/doc/[AssertJ]: A fluent assertion library.
* https://github.com/hamcrest/JavaHamcrest[Hamcrest]: A library of matcher objects (also known as constraints or predicates).
* https://site.mockito.org/[Mockito]: A Java mocking framework.
* https://github.com/skyscreamer/JSONassert[JSONassert]: An assertion library for JSON.
* https://github.com/jayway/JsonPath[JsonPath]: XPath for JSON.

We generally find these common libraries to be useful when writing tests.
If these libraries do not suit your needs, you can add additional test dependencies of your own.



[[features.testing.spring-applications]]
=== Testing Spring Applications
One of the major advantages of dependency injection is that it should make your code easier to unit test.
You can instantiate objects by using the `new` operator without even involving Spring.
You can also use _mock objects_ instead of real dependencies.

Often, you need to move beyond unit testing and start integration testing (with a Spring `ApplicationContext`).
It is useful to be able to perform integration testing without requiring deployment of your application or needing to connect to other infrastructure.

The Spring Framework includes a dedicated test module for such integration testing.
You can declare a dependency directly to `org.springframework:spring-test` or use the `spring-boot-starter-test` "`Starter`" to pull it in transitively.

If you have not used the `spring-test` module before, you should start by reading the {spring-framework-docs}/testing.html#testing[relevant section] of the Spring Framework reference documentation.



[[features.testing.spring-boot-applications]]
=== Testing Spring Boot Applications
A Spring Boot application is a Spring `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 `SpringApplication` to create it.

Spring Boot provides a `@SpringBootTest` annotation, which can be used as an alternative to the standard `spring-test` `@ContextConfiguration` annotation when you need Spring Boot features.
The annotation works by <<features#features.testing.spring-boot-applications.detecting-configuration,creating the `ApplicationContext` used in your tests through `SpringApplication`>>.
In addition to `@SpringBootTest` a number of other annotations are also provided for <<features#features.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 `@SpringBootTest` and the other `@...Test` annotations are already annotated with it.

By default, `@SpringBootTest` will not start a server.
You can use the `webEnvironment` attribute of `@SpringBootTest` to further refine how your tests run:

* `MOCK`(Default) : Loads a web `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 `ApplicationContext`.
	It can be used in conjunction with <<features#features.testing.spring-boot-applications.with-mock-environment, `@AutoConfigureMockMvc` or `@AutoConfigureWebTestClient`>> for mock-based testing of your web application.
* `RANDOM_PORT`: Loads a `WebServerApplicationContext` and provides a real web environment.
  Embedded servers are started and listen on a random port.
* `DEFINED_PORT`: Loads a `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 `ApplicationContext` by using `SpringApplication` but does not provide _any_ web environment (mock or otherwise).

NOTE: If your test is `@Transactional`, 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: `@SpringBootTest` 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.



[[features.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[]



[[features.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 `@Configuration` to load.
Alternatively, you might have often used nested `@Configuration` 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 `@SpringBootApplication` or `@SpringBootConfiguration`.
As long as you <<using#using.structuring-your-code, structured your code>> in a sensible way, your main configuration is usually found.

[NOTE]
====
If you use a <<features#features.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 <<features#features.testing.spring-boot-applications.user-configuration-and-slicing, main method's application class>>.

The underlying component scan configuration of `@SpringBootApplication` defines exclude filters that are used to make sure slicing works as expected.
If you are using an explicit `@ComponentScan` directive on your `@SpringBootApplication`-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 `@TestConfiguration` class.
Unlike a nested `@Configuration` class, which would be used instead of your application's primary configuration, a nested `@TestConfiguration` 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.



[[features.testing.spring-boot-applications.excluding-configuration]]
==== Excluding Test Configuration
If your application uses component scanning (for example, if you use `@SpringBootApplication` or `@ComponentScan`), you may find top-level configuration classes that you created only for specific tests accidentally get picked up everywhere.

As we <<features#features.testing.spring-boot-applications.detecting-configuration,have seen earlier>>, `@TestConfiguration` can be used on an inner class of a test to customize the primary configuration.
When placed on a top-level class, `@TestConfiguration` indicates that classes in `src/test/java` should not be picked up by scanning.
You can then import that class explicitly where it is required, as shown in the following example:

include::code:MyTests[]

NOTE: If you directly use `@ComponentScan` (that is, not through `@SpringBootApplication`) you need to register the `TypeExcludeFilter` with it.
See {spring-boot-module-api}/context/TypeExcludeFilter.html[the Javadoc] for details.



[[features.testing.spring-boot-applications.using-application-arguments]]
==== Using Application Arguments
If your application expects <<features#features.spring-application.application-arguments,arguments>>, you can
have `@SpringBootTest` inject them using the `args` attribute.

include::code:MyApplicationArgumentTests[]



[[features.testing.spring-boot-applications.with-mock-environment]]
==== Testing with a mock environment
By default, `@SpringBootTest` 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 {spring-framework-docs}/testing.html#spring-mvc-test-framework[`MockMvc`] or `WebTestClient`, as shown in the following example:

include::code:MyMockMvcTests[]

TIP: If you want to focus only on the web layer and not start a complete `ApplicationContext`, consider <<features#features.testing.spring-boot-applications.spring-mvc-tests,using `@WebMvcTest` instead>>.

With Spring WebFlux endpoints, you can use {spring-framework-docs}/testing.html#webtestclient-tests[`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 <<web#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.
====



[[features.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 `@LocalServerPort` annotation can be used to <<howto#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 {spring-framework-docs}/testing.html#webtestclient-tests[`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: `WebTestClient` can be used against both live servers and <<features#features.testing.spring-boot-applications.with-mock-environment, mock environments>>.

This setup requires `spring-webflux` on the classpath.
If you can not or will not add webflux, Spring Boot also provides a `TestRestTemplate` facility:

include::code:MyRandomPortTestRestTemplateTests[]



[[features.testing.spring-boot-applications.customizing-web-test-client]]
==== Customizing WebTestClient
To customize the `WebTestClient` bean, configure a `WebTestClientBuilderCustomizer` bean.
Any such beans are called with the `WebTestClient.Builder` that is used to create the `WebTestClient`.



[[features.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 `MBeanServer`, consider marking it dirty as well:

include::code:MyJmxTests[]



[[features.testing.spring-boot-applications.metrics]]
==== Using Metrics
Regardless of your classpath, meter registries, except the in-memory backed, are not auto-configured when using `@SpringBootTest`.

If you need to export metrics to a different backend as part of an integration test, annotate it with `@AutoConfigureObservability`.



[[features.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 Boot includes a `@MockBean` annotation that can be used to define a Mockito mock for a bean inside your `ApplicationContext`.
You can use the annotation to add new beans or replace a single existing bean definition.
The annotation can be used directly on test classes, on fields within your test, or on `@Configuration` classes and fields.
When used on a field, the instance of the created mock is also injected.
Mock beans are automatically reset after each test method.

[NOTE]
====
If your test uses one of Spring Boot's test annotations (such as `@SpringBootTest`), this feature is automatically enabled.
To use this feature with a different arrangement, listeners must be explicitly added, as shown in the following example:

include::code:listener/MyTests[]

====<commit_msg>Add tracing in integration tests paragraph to the documentation<commit_after>[[features.testing]]
== Testing
Spring Boot provides a number of utilities and annotations to help when testing your application.
Test support is provided by two modules: `spring-boot-test` contains core items, and `spring-boot-test-autoconfigure` supports auto-configuration for tests.

Most developers use the `spring-boot-starter-test` "`Starter`", which imports both Spring Boot test modules as well as JUnit Jupiter, AssertJ, Hamcrest, and a number of other useful libraries.

[TIP]
====
If you have tests that use JUnit 4, JUnit 5's vintage engine can be used to run them.
To use the vintage engine, add a dependency on `junit-vintage-engine`, as shown in the following example:

[source,xml,indent=0,subs="verbatim"]
----
	<dependency>
		<groupId>org.junit.vintage</groupId>
		<artifactId>junit-vintage-engine</artifactId>
		<scope>test</scope>
		<exclusions>
			<exclusion>
				<groupId>org.hamcrest</groupId>
				<artifactId>hamcrest-core</artifactId>
			</exclusion>
		</exclusions>
	</dependency>
----
====

`hamcrest-core` is excluded in favor of `org.hamcrest:hamcrest` that is part of `spring-boot-starter-test`.



[[features.testing.test-scope-dependencies]]
=== Test Scope Dependencies
The `spring-boot-starter-test` "`Starter`" (in the `test` `scope`) contains the following provided libraries:

* https://junit.org/junit5/[JUnit 5]: The de-facto standard for unit testing Java applications.
* {spring-framework-docs}/testing.html#integration-testing[Spring Test] & Spring Boot Test: Utilities and integration test support for Spring Boot applications.
* https://assertj.github.io/doc/[AssertJ]: A fluent assertion library.
* https://github.com/hamcrest/JavaHamcrest[Hamcrest]: A library of matcher objects (also known as constraints or predicates).
* https://site.mockito.org/[Mockito]: A Java mocking framework.
* https://github.com/skyscreamer/JSONassert[JSONassert]: An assertion library for JSON.
* https://github.com/jayway/JsonPath[JsonPath]: XPath for JSON.

We generally find these common libraries to be useful when writing tests.
If these libraries do not suit your needs, you can add additional test dependencies of your own.



[[features.testing.spring-applications]]
=== Testing Spring Applications
One of the major advantages of dependency injection is that it should make your code easier to unit test.
You can instantiate objects by using the `new` operator without even involving Spring.
You can also use _mock objects_ instead of real dependencies.

Often, you need to move beyond unit testing and start integration testing (with a Spring `ApplicationContext`).
It is useful to be able to perform integration testing without requiring deployment of your application or needing to connect to other infrastructure.

The Spring Framework includes a dedicated test module for such integration testing.
You can declare a dependency directly to `org.springframework:spring-test` or use the `spring-boot-starter-test` "`Starter`" to pull it in transitively.

If you have not used the `spring-test` module before, you should start by reading the {spring-framework-docs}/testing.html#testing[relevant section] of the Spring Framework reference documentation.



[[features.testing.spring-boot-applications]]
=== Testing Spring Boot Applications
A Spring Boot application is a Spring `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 `SpringApplication` to create it.

Spring Boot provides a `@SpringBootTest` annotation, which can be used as an alternative to the standard `spring-test` `@ContextConfiguration` annotation when you need Spring Boot features.
The annotation works by <<features#features.testing.spring-boot-applications.detecting-configuration,creating the `ApplicationContext` used in your tests through `SpringApplication`>>.
In addition to `@SpringBootTest` a number of other annotations are also provided for <<features#features.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 `@SpringBootTest` and the other `@...Test` annotations are already annotated with it.

By default, `@SpringBootTest` will not start a server.
You can use the `webEnvironment` attribute of `@SpringBootTest` to further refine how your tests run:

* `MOCK`(Default) : Loads a web `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 `ApplicationContext`.
	It can be used in conjunction with <<features#features.testing.spring-boot-applications.with-mock-environment, `@AutoConfigureMockMvc` or `@AutoConfigureWebTestClient`>> for mock-based testing of your web application.
* `RANDOM_PORT`: Loads a `WebServerApplicationContext` and provides a real web environment.
  Embedded servers are started and listen on a random port.
* `DEFINED_PORT`: Loads a `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 `ApplicationContext` by using `SpringApplication` but does not provide _any_ web environment (mock or otherwise).

NOTE: If your test is `@Transactional`, 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: `@SpringBootTest` 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.



[[features.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[]



[[features.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 `@Configuration` to load.
Alternatively, you might have often used nested `@Configuration` 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 `@SpringBootApplication` or `@SpringBootConfiguration`.
As long as you <<using#using.structuring-your-code, structured your code>> in a sensible way, your main configuration is usually found.

[NOTE]
====
If you use a <<features#features.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 <<features#features.testing.spring-boot-applications.user-configuration-and-slicing, main method's application class>>.

The underlying component scan configuration of `@SpringBootApplication` defines exclude filters that are used to make sure slicing works as expected.
If you are using an explicit `@ComponentScan` directive on your `@SpringBootApplication`-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 `@TestConfiguration` class.
Unlike a nested `@Configuration` class, which would be used instead of your application's primary configuration, a nested `@TestConfiguration` 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.



[[features.testing.spring-boot-applications.excluding-configuration]]
==== Excluding Test Configuration
If your application uses component scanning (for example, if you use `@SpringBootApplication` or `@ComponentScan`), you may find top-level configuration classes that you created only for specific tests accidentally get picked up everywhere.

As we <<features#features.testing.spring-boot-applications.detecting-configuration,have seen earlier>>, `@TestConfiguration` can be used on an inner class of a test to customize the primary configuration.
When placed on a top-level class, `@TestConfiguration` indicates that classes in `src/test/java` should not be picked up by scanning.
You can then import that class explicitly where it is required, as shown in the following example:

include::code:MyTests[]

NOTE: If you directly use `@ComponentScan` (that is, not through `@SpringBootApplication`) you need to register the `TypeExcludeFilter` with it.
See {spring-boot-module-api}/context/TypeExcludeFilter.html[the Javadoc] for details.



[[features.testing.spring-boot-applications.using-application-arguments]]
==== Using Application Arguments
If your application expects <<features#features.spring-application.application-arguments,arguments>>, you can
have `@SpringBootTest` inject them using the `args` attribute.

include::code:MyApplicationArgumentTests[]



[[features.testing.spring-boot-applications.with-mock-environment]]
==== Testing with a mock environment
By default, `@SpringBootTest` 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 {spring-framework-docs}/testing.html#spring-mvc-test-framework[`MockMvc`] or `WebTestClient`, as shown in the following example:

include::code:MyMockMvcTests[]

TIP: If you want to focus only on the web layer and not start a complete `ApplicationContext`, consider <<features#features.testing.spring-boot-applications.spring-mvc-tests,using `@WebMvcTest` instead>>.

With Spring WebFlux endpoints, you can use {spring-framework-docs}/testing.html#webtestclient-tests[`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 <<web#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.
====



[[features.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 `@LocalServerPort` annotation can be used to <<howto#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 {spring-framework-docs}/testing.html#webtestclient-tests[`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: `WebTestClient` can be used against both live servers and <<features#features.testing.spring-boot-applications.with-mock-environment, mock environments>>.

This setup requires `spring-webflux` on the classpath.
If you can not or will not add webflux, Spring Boot also provides a `TestRestTemplate` facility:

include::code:MyRandomPortTestRestTemplateTests[]



[[features.testing.spring-boot-applications.customizing-web-test-client]]
==== Customizing WebTestClient
To customize the `WebTestClient` bean, configure a `WebTestClientBuilderCustomizer` bean.
Any such beans are called with the `WebTestClient.Builder` that is used to create the `WebTestClient`.



[[features.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 `MBeanServer`, consider marking it dirty as well:

include::code:MyJmxTests[]

[[features.testing.spring-boot-applications.metrics]]
==== Using Metrics
Regardless of your classpath, meter registries, except the in-memory backed, are not auto-configured when using `@SpringBootTest`.

If you need to export metrics to a different backend as part of an integration test, annotate it with `@AutoConfigureObservability`.

[[features.testing.spring-boot-applications.tracing]]
==== Using Tracing
Regardless of your classpath, tracing is not auto-configured when using `@SpringBootTest`.

If you need tracing as part of an integration test, annotate it with `@AutoConfigureObservability`.

[[features.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 Boot includes a `@MockBean` annotation that can be used to define a Mockito mock for a bean inside your `ApplicationContext`.
You can use the annotation to add new beans or replace a single existing bean definition.
The annotation can be used directly on test classes, on fields within your test, or on `@Configuration` classes and fields.
When used on a field, the instance of the created mock is also injected.
Mock beans are automatically reset after each test method.

[NOTE]
====
If your test uses one of Spring Boot's test annotations (such as `@SpringBootTest`), this feature is automatically enabled.
To use this feature with a different arrangement, listeners must be explicitly added, as shown in the following example:

include::code:listener/MyTests[]

====
{'fraction_non_alphanumeric': 0.07517245825543163, 'fraction_numerical': 0.000709174134485204, 'mean_word_length': 5.45774354704413, 'pattern_counts': {'":': 0, '<': 83, '<?xml version=': 0, '>': 83, 'https://': 12, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6205287', 'n_tokens_mistral': 7874, 'n_tokens_neox': 7519, 'n_words': 3722}