This commit add mock support for WebFlux with an infrastructure similar
to what `WebMvcTest` provides. `@WebFluxTest` can be used to test
controllers with a narrowed classpath that is relevant to WebFlux. Also,
`@SpringBootTest` now starts WebFlux in "mock" mode by default and
`@AutoConfigureWebTestClient` can be used to inject a `WebTestClient`
connected to the `ApplicationContext`.
To make that happen, a `ReactiveWebApplicationContext` interface has been
introduced to mirror what `WebApplicationContext` currently does. Things
are still a bit volatile at this point and that infra may move to Spring
Framework at some point.
Closes gh-8401
This commit exposes a `WebTestClient` automatically in a reactive
integration test that uses an embedded web server. This is similar to
what we do with `TestRestTemplate` for servlet based integration tests.
Closes gh-8399
This commit makes sure that `@SpringBootTest` with a reactive setup
starts a web application if necessary.
If both a servlet and a reactive environment are available, a servlet
environment is bootstraped. This commit also adds a way to force a
reactive environment by specifying the `spring.main.web-application-type`
property of the test (e.g. `@TestPropertySource`).
Closes gh-8383
Previously, @SpyBean's name attribute was not used when determining
the name of the bean to spy upon. When there were multiple candidates,
none of which were primary, this would lead to a failure to find the
bean to spy upon. This behaviour is also inconsistent with @MockBean
which does use the name attribute to identify the bean to mock.
This commit updates MockitoPostProcessor to use the name attribute,
when set, to identify the bean that should be spied upon. For
consistency with @MockBean it is always used when set. When not set
the previous logic will continue to be used.
Closes gh-8315
This commit refactors the `ServerProperties` property keys and
introduces a separate "server.servlet" namespace to isolate
servlet-specific properties from the rest.
Closes gh-8066
This commit introduces a new variant of web applications: there are now
Servlet based and Reactive web applications.
The mere presence of `Servlet` and `ConfigurableWebApplicationContext`
classes is not enough to make a difference between those variants.
This is why the decision process is now the following:
* if `DispatcherHandler` is present but not `DispatcherServlet`, the
WebApplicationType is detected as REACTIVE
* if `DispatcherHandler` is present and `DispatcherServlet`, this is a
case where we consider that developers are using Spring MVC in
combination with the reactive web client. So WebApplicationType is
detected as SERVLET
* if `Servlet` and `ConfigurableWebApplicationContext` are present,
WebApplicationType is detected as SERVLET
* if none of the above match, WebApplicationType is NONE
Fixes gh-8017
Previously, TestRestTemplate applied the root URI to URIs by
converting them to a String and then passing the String to the
RestTemplate delegate. Being a String, meant that the URI passed
through RestTemplate's standard URI template expansion processing
using the configured UriTemplateHandler. While this caused the root
URI to be applied, it also had the unwanted side-effect of
encoding the URI for a second time.
This commit updates TestRestTemplate so that, when configured with a
RootUriTemplateHandler, it applies the root URI directly and then
passes a modified URI to the RestTemplate delegate. Being a URI means
that no template expansion is performed and the possible double
encoding is avoided.
Closes gh-8163
The caching behaviour when using ImportAutoConfiguration is covered
by tests in spring-boot-test-auto-configuration, specifically by
ImportsContextCustomizerFactoryWithAutoConfigurationTests.
See gh-7953
Update `ImportsContextCustomizer` so that whenever possible a more
specific cache key is used.
Prior to this commit the customizer would generate a key based on *all*
annotations on the test class. This has repeatedly caused issues where
test classes that should have the same cache key did not due to
unrelated annotations.
A new `DeterminableImports` interface has been added that can be
implemented by `ImportSelector` and `ImportBeanDefinitionRegistrar`
implementations that are able to determine their imports early. The
existing `ImportAutoConfigurationImportSelector` and
`AutoConfigurationPackages` classes have been retrofitted with
this interface.
Fixes gh-7953
Previously, TestRestTemplate would only apply the UriTemplateHandler
to Strings and not to URIs. When using the auto-configured
TestRestTemplate, this prevented relative URIs from being
made absolute using LocalHostUriTemplateHandler.
The commit updates TestRestTemplate to turn URIs into Strings before
passing them to the delegate RestTemplate. Turning them into Strings
ensures that the delegate calls the UriTemplateHandler.
Closes gh-7891
Update `TestRestTemplate` to handle `BasicAuthorizationInterceptor`s
correctly. Prior to this commit the `BasicAuthorizationInterceptor`
was added directly to the `ClientHttpRequestFactory` rather than
to the `RestTemplate`. This meant that it could not easily be removed
when `TestRestTemplate.withBasicAuth` was invoked.
The `TestRestTemplate` now sets the interceptor on `RestTemplate`
directly and relies on the logic in `InterceptingHttpAccessor` to
add it to the `ClientHttpRequestFactory`.
Fixes gh-7812
This commit allows to define `server.port` in a non-embedded web
environment. Previously, `server.port` would have been set to `-1`
regardless.
Closes gh-7353
Update `SpringBootTestContextCustomizer` to use the full qualified
TestRestTemplate as the registered bean name. Prior to this commit it
was possible that the customizer would replace the relatively common
bean name `testRestTemplate`.
Fixes gh-7711
Previously, ResetMocksTestExecutionListener used getBean(name) to
retrieve each instantiated singleton. When the instantiated singleton
was a factory bean, this would cause getObject on the factory bean to
be called. If the factory bean was unable to produce its object, for
example due to test slicing excluding something, an exception would
be thrown.
The previous commit updated ResetMocksTestsExecutionListener to
use getSingleton(name) rather than getBean(name). This will retrieve
the factory bean itself rather than causing the factory bean to
attempt to create an object. This commit updates the tests to verify
the new behaviour.
Closes gh-7270
We use some internal Mockito classes and some breaking API changes
have been made to them in Mockito 2. This commit introduces a utility
class, SpringBootMockUtil, to shield our code from these differences.
Mockito 1 is called directly and Mockito 2 is called via reflection.
To allow these changes to be tested, FilteredClassPathRunner has been
enhanced to also support overriding a dependency on the class path.
As a result it has been renamed to ModifiedClassPathRunner. The new
ClassPathOverrides annotation can be used to provide the Maven
coordinates of one or more dependencies that should be resolved and
added to the class path. Such additions are added to the start of
the class path so that they override any existing dependency that
contains the same classes.
Closes gh-6520
Every classes that's compiled by Kotlin is annotated with
kotlin.Metadata. The attributes of this annotation always differ so
if they are used in the cache key, context caching will effectively
be disabled.
This commit updates the key used by ImportsContextCustomizer to
ignore the kotlin.Metadata annotation. Additionally, to align with
with Java where annotations in java.lang.annotation are ignored,
annotations in kotlin.annotation are also ignored.
Closes gh-7101
Refine @MockBean/@SpyBean qualifier support so that qualifiers form part
of the context cache key. Prior to this commit is was possible that two
different tests could accidentally share the same context if they
defined the same @Mock but with different @Qualifiers.
See gh-6753
Previously, if an injection point used a qualifier, `MockBean` and
`SpyBean` couldn't be used to mock/spy it as there was no way to
specify that qualifier information.
This commit now detects qualifier information on the injection point
and associate it with the created `BeanDefintion`. If one wants to
mock a bean that is qualified with `@Qualifier("foo")`, the definition
of the mock should be as follows:
```
public class MyTest {
@MockBean
@Qualifier("foo")
private ExampleService service;
}
```
As a side effect, it is now possible to mock a service by type even if
there are multiple instances of that type in the application context. The
provided qualifier information is used to determine the right candidate
and the proper bean definition is replaced accordingly.
Closes gh-6753