Prior to this commit, it was only possible to register a
ContextCustomizerFactory in the TestContext framework (TCF) via the
SpringFactoriesLoader mechanism.
This commit introduces support for declarative registration of a
ContextCustomizerFactory local to a test class via a new
@ContextCustomizerFactories annotation.
Closes gh-26148
Prior to this commit, @BeforeTransaction and @AfterTransaction
methods could not accept any arguments. This is acceptable with testing
frameworks such as JUnit 4 and TestNG that do not provide support for
parameter injection. However, users of JUnit Jupiter have become
accustomed to being able to accept arguments in lifecycle methods
annotated with JUnit's @BeforeEach, @AfterEach, etc.
As a follow up to the previous commit (see gh-31199), this commit
introduces first-class support for parameter injection in
@BeforeTransaction and @AfterTransaction methods, as demonstrated in
the following example.
@BeforeTransaction
void verifyInitialDatabaseState(@Autowired DataSource dataSource) {
// Use the DataSource to verify the initial DB state
}
Closes gh-30736
In order to be able to support parameter injection in
@BeforeTransaction and @AfterTransaction methods (see gh-30736), this
commit introduces a MethodInvoker API for TestExecutionListeners as a
generic mechanism for delegating to the underlying testing framework to
invoke methods.
The default implementation simply invokes the method without arguments,
which allows TestExecutionListeners using this mechanism to operate
correctly when the underlying testing framework is JUnit 4, TestNG, etc.
A JUnit Jupiter specific implementation is registered in the
SpringExtension which delegates to the
ExtensionContext.getExecutableInvoker() mechanism introduced in JUnit
Jupiter 5.9. This allows a TestExecutionListener to transparently
benefit from registered ParameterResolvers in JUnit Jupiter (including
the SpringExtension) when invoking user methods, effectively providing
support for parameter injection for arbitrary methods.
Closes gh-31199
The tests were ignored due to "Fails against TestNG 6.11"; however,
these tests pass against the current version of TestNG that we build
against (7.8.0).
Prior to this commit, a dynamic property registered via a
@DynamicPropertySource method in a @Nested test class was not able to
override a property registered via a @DynamicPropertySource method in
the enclosing class.
See gh-26091
Closes gh-31083
Inspired by the recently added support for resource patterns in
@PropertySource locations, this commit adds the same support for
resource locations in @TestPropertySource.
For example, assuming the `config` folder in the classpath contains
only 3 files matching the pattern `file?.properties`,
... the following:
@TestPropertySource("classpath:/config/file1.properties")
@TestPropertySource("classpath:/config/file2.properties")
@TestPropertySource("classpath:/config/file3.properties")
... or:
@TestPropertySource({
"classpath:/config/file1.properties",
"classpath:/config/file2.properties",
"classpath:/config/file3.properties"
})
... can now be replaced by:
@TestPropertySource("classpath*:/config/file?.properties")
See gh-21325
Closes gh-31055
Prior to this commit, inlined properties could only be supplied as an
array of Strings as follows.
@TestPropertySource(properties = {
"key1 = value1",
"key2 = value2"
})
Although a user could supply a text block, it was previously rejected
due to a "single key-value pair per string" check in
TestPropertySourceUtils.convertInlinedPropertiesToMap(String...).
This commit removes that restriction and allows the above example to be
refactored to use a text block as follows.
@TestPropertySource(properties = """
key1 = value1
key2 = value2
"""
)
Closes gh-31053
This commit makes the recently introduced
addPropertySourcesToEnvironment(ConfigurableEnvironment, ResourceLoader,
List<PropertySourceDescriptor>) method in TestPropertySourceUtils public
so that it can be used by third parties (for example, Spring Boot).
Closes gh-30981
Prior to this commit, property files configured (or inferred) via
@TestPropertySource were read using the default encoding of the JVM.
This commit introduces an `encoding` attribute in @TestPropertySource
which allows developers to specify an explicit encoding for test
property files.
Closes gh-30982
Spring Framework 4.3 introduced the `PropertySourceFactory` SPI for use
with `@PropertySource` on `@Configuration` classes; however, prior to
this commit there was no mechanism to support custom properties file
formats in `@TestPropertySource` for integration tests.
This commit introduces support for configuring a custom
`PropertySourceFactory` via a new `factory` attribute in
`@TestPropertySource` in order to support custom file formats such as
JSON, YAML, etc.
For example, if you create a YamlPropertySourceFactory, you can use it
in integration tests as follows.
@SpringJUnitConfig
@TestPropertySource(locations = "/test.yaml", factory = YamlPropertySourceFactory.class)
class MyTestClass { /* ... /* }
If a custom factory is not specified, traditional `*.properties` and
`*.xml` based `java.util.Properties` file formats are supported, which
was the existing behavior.
Closes gh-30981
Prior to this commit, if an error was encountered during build-time AOT
processing, the error was logged at WARN/DEBUG level, and processing
continued.
With this commit, test AOT processing now fails on error by default. In
addition, the `failOnError` mode can be disabled by setting the
`spring.test.aot.processing.failOnError` Spring/System property to
`false`.
Closes gh-30977
rstoyanchev
Sam Brannen
ali dandach
Florian Lehmann
Juergen Hoeller
Yanming Zhou