For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public.
This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource.
In addition, the following house cleaning has been performed.
- deleted MockPropertySource from the spring-expression module
- deleted MockEnvironment from the "spring" integration testing module
- updated test copies of MockPropertySource and MockEnvironment
- documented MockEnvironment and MockPropertySource in the testing
chapter of the reference manual
Issue: SPR-9492
Currently the Spring TestContext Framework looks up a
PlatformTransactionManager bean named "transactionManager". The exact
name of the bean can be overridden via @TransactionConfiguration or
@Transactional; however, the bean will always be looked up 'by name'.
The TransactionManagementConfigurer interface that was introduced in
Spring 3.1 provides a programmatic approach to specifying the
PlatformTransactionManager bean to be used for annotation-driven
transaction management, and that bean is not required to be named
"transactionManager". However, as of Spring 3.1.2, using the
TransactionManagementConfigurer on a @Configuration class has no effect
on how the TestContext framework looks up the transaction manager.
Consequently, if an explicit name or qualifier has not been specified,
the bean must be named "transactionManager" in order for a transactional
integration test to work.
This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it looks up and delegates to
a single TransactionManagementConfigurer as part of the algorithm for
determining the transaction manager.
Issue: SPR-9604
TransactionalTestExecutionListener currently requires that the
PlatformTransactionManager bean be named "transactionManager" by
default. Otherwise, the bean name can only be overridden via the
transactionManager attribute of @TransactionConfiguration or the value
attribute of @Transactional.
However, if there is only a single PlatformTransactionManager in the
test's ApplicationContext, then the requirement to specify the exact
name of that bean (or to name it exactly "transactionManager") is often
superfluous.
This commit addresses this issue by refactoring the
TransactionalTestExecutionListener so that it is comparable to the
algorithm for determining the transaction manager used in
TransactionAspectSupport for "production" code. Specifically, the TTEL
now uses the following algorithm to retrieve the transaction manager.
- look up by type and qualifier from @Transactional
- else, look up by type and explicit name from
@TransactionConfiguration
- else, look up single bean by type
- else, look up by type and default name from @TransactionConfiguration
Issue: SPR-9645
The reference manual currently documents the wrong file name for the
default data SQL script used by EmbeddedDatabaseBuilder. In addition,
the testing chapter of the reference manual does not link to the testing
section of the JDBC chapter.
- Updated the "Testing data access logic with an embedded database"
section of the reference manual appropriately.
- Added a new paragraph to the "JDBC Testing Support" section of the
testing chapter which cross references the "Testing data access logic
with an embedded database" section.
Issue: SPR-9467
The reference manual previously did not mention the applicability of
JSR-250 lifecycle annotations within the TestContext framework. The
lacking documentation here has lead to misunderstandings of the support
provided for @PostConstruct and @PreDestroy in test classes.
The testing chapter of the reference manual has therefore been updated
to explicitly define the limited support for these annotations.
Also introduced Jsr250LifecycleTests for empirical verification of the
expected behavior.
Issue: SPR-4868
Updated the testing chapter of the reference manual to refer to
'annotated classes' instead of 'configuration classes' where
appropriate.
Also revised the content and examples in the @ContextConfiguration
annotation section, mentioned Gradle, and reformatted the entire text.
Issue: SPR-9401
This change eliminates the spring-framework-reference subproject, moving
these sources into the root project's own src directory.
This makes sense because the reference docs span all submodules, and
also because api Javadoc is created at the root project level as well.
This means that both api and reference documentation output will now
reside in the root project's 'build' directory. This is more consistent
and easy to discover.
Sam Brannen
Chris Beams