Spring/spring-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Use convention based code imports

Browse Source 
Closes gh-29647
This commit is contained in:
Phillip Webb
2022-02-03 15:01:30 -08:00
parent 71695d2162
commit 0e906dc6e2
57 changed files with 250 additions and 967 deletions
Download Patch File Download Diff File Expand all files Collapse all files

255
spring-boot-project/spring-boot-docs/src/docs/asciidoc/features/testing.adoc
View File

@@ -105,10 +105,7 @@ If you have only Spring WebFlux, we will detect that and configure a WebFlux-bas
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/detectingwebapptype/MyWebFluxTests.java[]
----
include::code:MyWebFluxTests[]
@@ -148,10 +145,7 @@ As we <<features#features.testing.spring-boot-applications.detecting-configurati
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/excludingconfiguration/MyTests.java[]
----
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.
@@ -163,10 +157,7 @@ See {spring-boot-module-api}/context/TypeExcludeFilter.html[the Javadoc] for det
If your application expects <<features#features.spring-application.application-arguments,arguments>>, you can
have `@SpringBootTest` inject them using the `args` attribute.
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/usingapplicationarguments/MyApplicationArgumentTests.java[]
----
include::code:MyApplicationArgumentTests[]
@@ -176,19 +167,13 @@ By default, `@SpringBootTest` does not start the server but instead sets up a mo
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/withmockenvironment/MyMockMvcTests.java[]
----
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/withmockenvironment/MyMockWebTestClientTests.java[]
----
include::code:MyMockWebTestClientTests[]
[TIP]
====
@@ -210,20 +195,14 @@ If you use `@SpringBootTest(webEnvironment=WebEnvironment.RANDOM_PORT)`, an avai
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/withrunningserver/MyRandomPortWebTestClientTests.java[]
----
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/withrunningserver/MyRandomPortTestRestTemplateTests.java[]
----
include::code:MyRandomPortTestRestTemplateTests[]
@@ -239,10 +218,7 @@ Any such beans are called with the `WebTestClient.Builder` that is used to creat
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/jmx/MyJmxTests.java[]
----
include::code:MyJmxTests[]
@@ -271,19 +247,13 @@ Mock beans are automatically reset after each test method.
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/mockingbeans/listener/MyTests.java[]
----
include::code:listener/MyTests[]
====
The following example replaces an existing `RemoteService` bean with a mock implementation:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/mockingbeans/bean/MyTests.java[]
----
include::code:bean/MyTests[]
NOTE: `@MockBean` cannot be used to mock the behavior of a bean that is exercised during application context refresh.
By the time the test is executed, the application context refresh has completed and it is too late to configure the mocked behavior.
@@ -346,10 +316,7 @@ The `JacksonTester`, `GsonTester`, `JsonbTester`, and `BasicJsonTester` classes
Any helper fields on the test class can be `@Autowired` when using `@JsonTest`.
The following example shows a test class for Jackson:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/jsontests/MyJsonTests.java[]
----
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 `@Before` method if you do not use `@JsonTest`.
@@ -358,10 +325,7 @@ If you use Spring Boot's AssertJ-based helpers to assert on a number value at a
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`.
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/jsontests/MyJsonAssertJTests.java[tag=*]
----
include::code:MyJsonAssertJTests[tag=*]
@@ -384,20 +348,14 @@ Mock MVC offers a powerful way to quickly test MVC controllers without needing t
TIP: You can also auto-configure `MockMvc` in a non-`@WebMvcTest` (such as `@SpringBootTest`) by annotating it with `@AutoConfigureMockMvc`.
The following example uses `MockMvc`:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/springmvctests/MyControllerTests.java[]
----
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 `@AutoConfigureMockMvc` annotation.
If you use HtmlUnit and Selenium, auto-configuration also provides an HtmlUnit `WebClient` bean and/or a Selenium `WebDriver` bean.
The following example uses HtmlUnit:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/springmvctests/MyHtmlUnitTests.java[]
----
include::code:MyHtmlUnitTests[]
NOTE: By default, Spring Boot puts `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("singleton")` to your `WebDriver` `@Bean` definition.
@@ -431,10 +389,7 @@ Often, `@WebFluxTest` is limited to a single controller and used in combination
TIP: You can also auto-configure `WebTestClient` in a non-`@WebFluxTest` (such as `@SpringBootTest`) by annotating it with `@AutoConfigureWebTestClient`.
The following example shows a class that uses both `@WebFluxTest` and a `WebTestClient`:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/springwebfluxtests/MyControllerTests.java[]
----
include::code:MyControllerTests[]
TIP: This setup is only supported by WebFlux applications as using `WebTestClient` in a mocked web application only works with WebFlux at the moment.
@@ -495,10 +450,7 @@ TIP: If you need to register extra components, such as Jackson `Module`, you can
Often, `@GraphQlTest` is limited to a set of controllers and used in combination with the `@MockBean` annotation to provide mock implementations for required collaborators.
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/springgraphqltests/GreetingControllerTests.java[]
----
include::code:GreetingControllerTests[]
TIP: You can also auto-configure `WebGraphQlTester` in a non-`@GraphQlTest` (such as `@SpringBootTest`) by annotating it with `@AutoConfigureWebGraphQlTester`.
@@ -516,10 +468,7 @@ TIP: A list of the auto-configuration settings that are enabled by `@DataCassand
The following example shows a typical setup for using Cassandra tests in Spring Boot:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdatacassandra/MyDataCassandraTests.java[]
----
include::code:MyDataCassandraTests[]
@@ -540,10 +489,7 @@ By default, data JPA tests are transactional and roll back at the end of each te
See the {spring-framework-docs}/testing.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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdatajpa/MyNonTransactionalTests.java[]
----
include::code:MyNonTransactionalTests[]
Data JPA tests may also inject a {spring-boot-test-autoconfigure-module-code}/orm/jpa/TestEntityManager.java[`TestEntityManager`] bean, which provides an alternative to the standard JPA `EntityManager` that is specifically designed for tests.
@@ -553,18 +499,12 @@ When doing so, make sure that your test is running in a transaction, for instanc
A `JdbcTemplate` is also available if you need that.
The following example shows the `@DataJpaTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdatajpa/withoutdb/MyRepositoryTests.java[]
----
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 `@AutoConfigureTestDatabase` annotation, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdatajpa/withdb/MyRepositoryTests.java[]
----
include::code:withdb/MyRepositoryTests[]
@@ -581,10 +521,7 @@ By default, JDBC tests are transactional and roll back at the end of each test.
See the {spring-framework-docs}/testing.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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredjdbc/MyTransactionalTests.java[]
----
include::code:MyTransactionalTests[]
If you prefer your test to run against a real database, you can use the `@AutoConfigureTestDatabase` annotation in the same way as for `DataJpaTest`.
(See "<<features#features.testing.spring-boot-applications.autoconfigured-spring-data-jpa>>".)
@@ -623,10 +560,7 @@ TIP: A list of the auto-configurations that are enabled by `@JooqTest` can be <<
`@JooqTest` configures a `DSLContext`.
The following example shows the `@JooqTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredjooq/MyJooqTests.java[]
----
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 <<features#features.testing.spring-boot-applications.autoconfigured-jdbc,shown in the JDBC example>>.
@@ -645,18 +579,12 @@ TIP: A list of the auto-configuration settings that are enabled by `@DataMongoTe
The following class shows the `@DataMongoTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdatamongodb/withoutdb/MyDataMongoDbTests.java[]
----
include::code:withoutdb/MyDataMongoDbTests[]
In-memory embedded MongoDB 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 MongoDB server, you should exclude the embedded MongoDB auto-configuration, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdatamongodb/withdb/MyDataMongoDbTests.java[]
----
include::code:withdb/MyDataMongoDbTests[]
@@ -672,19 +600,13 @@ TIP: A list of the auto-configuration settings that are enabled by `@DataNeo4jTe
The following example shows a typical setup for using Neo4J tests in Spring Boot:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdataneo4j/propagation/MyDataNeo4jTests.java[]
----
include::code:propagation/MyDataNeo4jTests[]
By default, Data Neo4j tests are transactional and roll back at the end of each test.
See the {spring-framework-docs}/testing.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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdataneo4j/nopropagation/MyDataNeo4jTests.java[]
----
include::code:nopropagation/MyDataNeo4jTests[]
NOTE: Transactional tests are not supported with reactive access.
If you are using this style, you must configure `@DataNeo4jTest` tests as described above.
@@ -703,10 +625,7 @@ TIP: A list of the auto-configuration settings that are enabled by `@DataRedisTe
The following example shows the `@DataRedisTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdataredis/MyDataRedisTests.java[]
----
include::code:MyDataRedisTests[]
@@ -722,18 +641,12 @@ TIP: A list of the auto-configuration settings that are enabled by `@DataLdapTes
The following example shows the `@DataLdapTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdataldap/inmemory/MyDataLdapTests.java[]
----
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringdataldap/server/MyDataLdapTests.java[]
----
include::code:server/MyDataLdapTests[]
@@ -748,10 +661,7 @@ TIP: A list of the auto-configuration settings that are enabled by `@RestClientT
The specific beans that you want to test should be specified by using the `value` or `components` attribute of `@RestClientTest`, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredrestclient/MyRestClientTests.java[]
----
include::code:MyRestClientTests[]
@@ -770,26 +680,17 @@ It can also be used to configure the host, scheme, and port that appears in any
`@AutoConfigureRestDocs` customizes the `MockMvc` bean to use Spring REST Docs when testing servlet-based web applications.
You can inject it by using `@Autowired` and use it in your tests as you normally would when using Mock MVC and Spring REST Docs, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withmockmvc/MyUserDocumentationTests.java[]
----
include::code:MyUserDocumentationTests[]
If you require more control over Spring REST Docs configuration than offered by the attributes of `@AutoConfigureRestDocs`, you can use a `RestDocsMockMvcConfigurationCustomizer` bean, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withmockmvc/MyRestDocsConfiguration.java[]
----
include::code:MyRestDocsConfiguration[]
If you want to make use of Spring REST Docs support for a parameterized output directory, you can create a `RestDocumentationResultHandler` bean.
The auto-configuration calls `alwaysDo` with this result handler, thereby causing each `MockMvc` call to automatically generate the default snippets.
The following example shows a `RestDocumentationResultHandler` being defined:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withmockmvc/MyResultHandlerConfiguration.java[]
----
include::code:MyResultHandlerConfiguration[]
@@ -798,25 +699,16 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredsprin
`@AutoConfigureRestDocs` can also be used with `WebTestClient` when testing reactive web applications.
You can inject it by using `@Autowired` and use it in your tests as you normally would when using `@WebFluxTest` and Spring REST Docs, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withwebtestclient/MyUsersDocumentationTests.java[]
----
include::code:MyUsersDocumentationTests[]
If you require more control over Spring REST Docs configuration than offered by the attributes of `@AutoConfigureRestDocs`, you can use a `RestDocsWebTestClientConfigurationCustomizer` bean, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withwebtestclient/MyRestDocsConfiguration.java[]
----
include::code:MyRestDocsConfiguration[]
If you want to make use of Spring REST Docs support for a parameterized output directory, you can use a `WebTestClientBuilderCustomizer` to configure a consumer for every entity exchange result.
The following example shows such a `WebTestClientBuilderCustomizer` being defined:
[source,java,indent=0]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withwebtestclient/MyWebTestClientBuilderCustomizerConfiguration.java[]
----
include::code:MyWebTestClientBuilderCustomizerConfiguration[]
@@ -825,17 +717,11 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredsprin
`@AutoConfigureRestDocs` makes a `RequestSpecification` bean, preconfigured to use Spring REST Docs, available to your tests.
You can inject it by using `@Autowired` and use it in your tests as you normally would when using REST Assured and Spring REST Docs, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withrestassured/MyUserDocumentationTests.java[]
----
include::code:MyUserDocumentationTests[]
If you require more control over Spring REST Docs configuration than offered by the attributes of `@AutoConfigureRestDocs`, a `RestDocsRestAssuredConfigurationCustomizer` bean can be used, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredspringrestdocs/withrestassured/MyRestDocsConfiguration.java[]
----
include::code:MyRestDocsConfiguration[]
@@ -855,10 +741,7 @@ TIP: A list of the auto-configuration settings that are enabled by `@WebServiceC
The following example shows the `@WebServiceClientTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredwebservices/client/MyWebServiceClientTests.java[]
----
include::code:MyWebServiceClientTests[]
@@ -873,10 +756,7 @@ TIP: A list of the auto-configuration settings that are enabled by `@WebServiceS
The following example shows the `@WebServiceServerTest` annotation in use:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/autoconfiguredwebservices/server/MyWebServiceServerTests.java[]
----
include::code:MyWebServiceServerTests[]
@@ -885,10 +765,7 @@ include::{docs-java}/features/testing/springbootapplications/autoconfiguredwebse
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 `@ImportAutoConfiguration` to the test as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/additionalautoconfigurationandslicing/MyJdbcTests.java[]
----
include::code:MyJdbcTests[]
NOTE: Make sure to not use the regular `@Import` annotation to import auto-configurations as they are handled in a specific way by Spring Boot.
@@ -912,18 +789,12 @@ It then becomes important not to litter the application's main class with config
Assume that you are using Spring Batch and you rely on the auto-configuration for it.
You could define your `@SpringBootApplication` as follows:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/userconfigurationandslicing/MyApplication.java[]
----
include::code:MyApplication[]
Because this class is the source configuration for the test, any slice test actually tries to start Spring Batch, which is definitely not what you want to do.
A recommended approach is to move that area-specific configuration to a separate `@Configuration` class at the same level as your application, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/userconfigurationandslicing/MyBatchConfiguration.java[]
----
include::code:MyBatchConfiguration[]
NOTE: Depending on the complexity of your application, you may either have a single `@Configuration` 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 `@Import` annotation.
@@ -931,26 +802,17 @@ The latter approach lets you enable it in one of your tests, if necessary, with
Test slices exclude `@Configuration` classes from scanning.
For example, for a `@WebMvcTest`, the following configuration will not include the given `WebMvcConfigurer` bean in the application context loaded by the test slice:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/userconfigurationandslicing/MyWebConfiguration.java[]
----
include::code:MyWebConfiguration[]
The configuration below will, however, cause the custom `WebMvcConfigurer` to be loaded by the test slice.
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/userconfigurationandslicing/MyWebMvcConfigurer.java[]
----
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:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/springbootapplications/userconfigurationandslicing/scan/MyApplication.java[]
----
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 `@DataJpaTest` seems to suddenly scan components and user configurations of your application.
@@ -981,10 +843,7 @@ A few test utility classes that are generally useful when testing your applicati
`ConfigDataApplicationContextInitializer` is an `ApplicationContextInitializer` that you can apply to your tests to load Spring Boot `application.properties` files.
You can use it when you do not need the full set of features provided by `@SpringBootTest`, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/utilities/configdataapplicationcontextinitializer/MyConfigFileTests.java[]
----
include::code:MyConfigFileTests[]
NOTE: Using `ConfigDataApplicationContextInitializer` alone does not provide support for `@Value("${...}")` injection.
Its only job is to ensure that `application.properties` files are loaded into Spring's `Environment`.
@@ -997,10 +856,7 @@ For `@Value` support, you need to either additionally configure a `PropertySourc
`TestPropertyValues` lets you quickly add properties to a `ConfigurableEnvironment` or `ConfigurableApplicationContext`.
You can call it with `key=value` strings, as follows:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/utilities/testpropertyvalues/MyEnvironmentTests.java[]
----
include::code:MyEnvironmentTests[]
@@ -1009,10 +865,7 @@ include::{docs-java}/features/testing/utilities/testpropertyvalues/MyEnvironment
`OutputCapture` is a JUnit `Extension` that you can use to capture `System.out` and `System.err` output.
To use add `@ExtendWith(OutputCaptureExtension.class)` and inject `CapturedOutput` as an argument to your test class constructor or test method as follows:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/utilities/outputcapture/MyOutputCaptureTests.java[]
----
include::code:MyOutputCaptureTests[]
@@ -1036,16 +889,10 @@ If you do use Apache's HTTP client, some additional test-friendly features are e
`TestRestTemplate` can be instantiated directly in your integration tests, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/utilities/testresttemplate/MyTests.java[]
----
include::code:MyTests[]
Alternatively, if you use the `@SpringBootTest` annotation with `WebEnvironment.RANDOM_PORT` or `WebEnvironment.DEFINED_PORT`, you can inject a fully configured `TestRestTemplate` and start using it.
If necessary, additional customizations can be applied through the `RestTemplateBuilder` bean.
Any URLs that do not specify a host and port automatically connect to the embedded server, as shown in the following example:
[source,java,indent=0,subs="verbatim"]
----
include::{docs-java}/features/testing/utilities/testresttemplate/MySpringBootTests.java[]
----
include::code:MySpringBootTests[]