Previously, the web environment configured on `@SpringBootTest` was not
part of the context cache key. As a result, two test classes that has
identical configuration other than one using a MOCK web environment and
the other using a DEFINED_PORT web environment would share a context
when they should not do so. Classes that use MOCK and RANDOM_PORT were
not affected as the use of RANDOM_PORT results in a property for the
port being added to the environment.
This commit adds a new ContextCustomizer, SpringBootTestWebEnvironment,
that is used to capture the `webEnvironment` from `@SpringBootTest`
and use it in its hashCode and equals implementations. This fixes the
problem as all context customizers are evaluated when determing the
equality of two context cache keys.
Fixes gh-23085
The fix for gh-20916 updated DefinitionsParser so that the
ResolvableType for each MockBean or SpyBean field included the
implementation class from which the field was found. Where the field
was declared with a variable generic signature that was made constant
by its implementation class, this allowed the correct concrete type to
be determined. It also had the unintended side-effect of preventing two
test classes with identical `@MockBean` and `@SpyBean` configuration
from sharing a context as the resolvable types for their mock and spy
bean fields would now be different.
This commit updates DefinitionsParser to only include the
implementation class in the ResolvableType if the field's generic type
is variable. For cases where it is not variable, this restores the
behaviour prior to the fix for gh-20916.
Fixes gh-22566
Previously, Spring Boot's modules published Gradle Module Metadata
(GMM) the declared a platform dependency on spring-boot-dependencies.
This provided versions for each module's own dependencies but also had
they unwanted side-effect of pulling in spring-boot-dependencies
constraints which would influence the version of other dependencies
declared in the same configuration. This was undesirable as users
should be able to opt in to this level of dependency management, either
by using the dependency management plugin or by using Gradle's built-in
support via a platform dependency on spring-boot-dependencies.
This commit reworks how Spring Boot's build uses
spring-boot-dependencies and spring-boot-parent to provide its own
dependency management. Configurations that aren't seen by consumers are
configured to extend a dependencyManagement configuration that has an
enforced platform dependency on spring-boot-parent. This enforces
spring-boot-parent's version constraints on Spring Boot's build without
making them visible to consumers. To ensure that the versions that
Spring Boot has been built against are visible to consumers, the
Maven publication that produces pom files and GMM for the published
modules is configured to use the resolved versions from the module's
runtime classpath.
Fixes gh-21911
Update `SpringBootContextLoader` to both add `spring.profiles.active`
properties and to directly call `Environment.setActiveProfiles`.
The additional `setActiveProfiles` call prevents `AbstractEnvironment`
from accidentally loading `spring.profiles.active` properties directly
when `doGetActiveProfiles` is called.
Directly setting active profiles has only become necessary since we
started adding properties using the square bracket notation. Previously
we added a comma-separated list which would be picked up by both the
`AbstractEnvironment` and the `ConfigurationFileApplicationListener`.
Closes gh-21302
Update `SpringBootContextLoader` so that it correctly deals with an
`@ActiveProfiles` annotation that contains a comma.
Fixes gh-19537
Co-authored-by: Scott Frederick <sfrederick@pivotal.io>
Co-authored-by: Andy Wilkinson <awilkinson@pivotal.io>
