Previously, JsonContentAssert returns AbstractMapAssert from
extractingJsonPathMapValue. This could lead to type safety warnings
when calling one of the assert's methods with a generic varargs
parameter such as
contains(Entry<? extends Object, ? extends Object>...).
This commit replaces the use of both AbstractMapAssert and
AbstractListAssert with MapAssert and ListAssert respectively. These
classes use final methods and @SafeVargs args to prevent the
above-described problem from occurring.
See gh-9675
Rename `ContextLoader` to `ApplicationContextTester` and provide
distinct subclasses for standard, web and reactive application contexts.
Context callbacks now return AssertJ compatible contexts, allowing
tests to run directly on context. For example:
context.run((loaded) -> assertThat(loaded).hasBean("foo"));
The returned context can now also represent a context that has failed
to start (meaning that the `loadAndFail` methods are no longer needed):
context.run((loaded) -> assertThat(loaded).hasFailed());
Configuration classes are loaded via the recently introduced
`Configurations` class. This means that the tester no longer needs to
be directly aware of auto-configuration concepts.
See gh-9634
Update `TestPropertyValues` so that it can also be used to update
system properties. Properties are set before the call is made and
restored to their previous value afterwards.
Fixes gh-9792
This commit applies what's been done in gh-9166 for WebFlux client and
server, but for the `WebTestClient` auto-configuration.
`WebTestClient` can be configured for mock or integration tests and this
change applies `CodecCustomizer` beans to the client being built.
Closes gh-9577
This commit adds ContextLoader, a test helper that configures an
ApplicationContext that is meant to simulate a particular
auto-configuration scenario.
The auto-configuration, user configuration and environment can be
customized. The loader invokes a ContextConsumer to assert the context
and automatically close the context once it is done.
Concretely, tests can create a shared field instance of that helper with
the shared configuration to increase its visibility and tune the context
further in each test.
If the context is expected to fail, `loadAndFail` allows to optionally
assert the root exception and consume it for further assertions.
This commit also migrates some tests to illustrate the practical use of
the helper
Closes gh-9634
Remove test-jar artifacts from Maven projects and relocate classes. The
majority of utilities now live in the `spring-boot-testsupport` module.
This update will help us to deploy artifacts using the standard Maven
deploy plugin in the future (which doesn't support the filtering of
individual artifacts).
Fixes gh-9493
Update `SpringApplication` so that the `run` methods and constructors
now require `Class<?>` arguments, rather than `Objects`. String based
sources can still be loaded, but must now be set on the `getSources()`
collections. `Package` and `Resource` types are no longer directly
supported.
This change should help IDEs offer better content assist, and will
help integrations with alternative languages such as Ceylon.
Users currently passing in Class references or using the
`spring.main.sources` property should not be affected by this change. If
an XML resource is being used, some refactoring may be required (see the
changes to `SampleSpringXmlApplication` in this commit).
Fixes gh-9170
Rework the ConfigurationPropertySources and related adapter classes to
help with performance. The ConfigurationPropertySources class now only
monitors for updates when `.attach` is used. The `.get` methods now
return the adapted version, but no longer checks to see if sources have
been added or removed on each call.
This commit also fixes a few caching issues and makes both the
`PropertyMapper` implementations true static singletons.
See gh-9000
Relax `SpringBootTestContextBootstrapper` rules so that a test can
specify an `ApplicationContextInitializer` and still have
`@SpringBootConfiguration` detected.
Prior to this commit detection would not occur because it's possible
that an initializer _could_ register configuration. This scenario is
actually quite unlikely to occur, certainly less likely than wanting to
use an initializer in combination with auto-detection.
Fixes gh-8483
Update SpringBootTestContextBootstrapper to detect `@ContextHierarchy`
annotations so that only the last child creates a
`WebApplicationContext`.
Prior to this commit a context hierarchy would start two embedded web
servers which is inconsistent with the `SpringApplicationBuilder`
behavior.
Fixes gh-8311