Once the new bootstrap strategy for the TestContext framework (TCF) is
introduced in Spring Framework 4.1, a TestContextBootstrapper will
assume full responsibility for determining what ContextLoader to use as
the default. Consequently, the previous support for supplying the class
name for a custom, default ContextLoader will no longer be applicable.
This commit therefore officially deprecates support for custom, default
ContextLoader class names via the following mechanisms:
- The TestContextManager(Class, String) constructor
- The getDefaultContextLoaderClassName(Class) method in
SpringJUnit4ClassRunner
Issue: SPR-11682
Since a dedicated bootstrap strategy will be introduced for the
TestContext framework in Spring Framework 4.1, this commit officially
deprecates TestContextManager.getDefaultTestExecutionListenerClasses()
as a forewarning to developers or frameworks that may be using this
obscure feature.
Issue: SPR-11679
Prior to this commit, the Spring TestContext Framework did not support
the declaration of both 'locations' and 'classes' within
@ContextConfiguration at the same time.
This commit addresses this in the following manner:
- ContextConfigurationAttributes no longer throws an
IllegalArgumentException if both 'locations' and 'classes' are
supplied to its constructor.
- Concrete SmartContextLoader implementations now validate the
supplied MergedContextConfiguration before attempting to load the
ApplicationContext. See validateMergedContextConfiguration().
- Introduced tests for hybrid context loaders like the one used in
Spring Boot. See HybridContextLoaderTests.
- Updated the Testing chapter of the reference manual so that it no
longer states that locations and classes cannot be used
simultaneously, mentioning Spring Boot as well.
- The Javadoc for @ContextConfiguration has been updated accordingly.
- Added hasLocations(), hasClasses(), and hasResources() convenience
methods to MergedContextConfiguration.
Issue: SPR-11634
(cherry picked from commit 1f017c4acb)
Prior to this commit, if multiple test methods were executed in a
subclass of AbstractTestNGSpringContextTests annotated with
@WebAppConfiguration, then injected Servlet API mocks would only
reference the mocks created for the first test method. Subsequent test
methods could therefore never reference the current mocks, and there
was a discrepancy between the state of the injected mocks and the mock
set in the RequestContextHolder.
This commit addresses this issue by ensuring that dependencies
(including updated mocks) are injected into the test instance before
the next test method if the ServletTestExecutionListener resets the
request attributes in RequestContextHolder.
Issue: SPR-11626
(cherry picked from commit c38600762d)
This commit adds new MockHttpServletRequestBuilder constructors
with an URI parameter in addition to the URL template + URL variables
existing ones.
It gives more control on how the URL is built, allowing for example to
use URL variables containing '/' character with proper encoding.
Issue: SPR-11441
This commit continues the work in the previous commit as follows:
- Introduced an exception hierarchy for exceptions related to SQL
scripts, with ScriptException as the base.
- CannotReadScriptException and ScriptStatementFailedException now
extend ScriptException.
- Introduced ScriptParseException, used by ScriptUtils.splitSqlScript().
- DatabasePopulatorUtils.execute() now explicitly throws a
DataAccessException.
- Polished Javadoc in ResourceDatabasePopulator.
- Overhauled Javadoc in ScriptUtils and documented all constants.
- Added missing @author tags for original authors in ScriptUtils and
ScriptUtilsTests.
- ScriptUtils.splitSqlScript() now asserts preconditions.
- Deleted superfluous methods in ScriptUtils and changed method
visibility to private or package private as appropriate.
- Deleted the ScriptStatementExecutor introduced in the previous
commit; ScriptUtils.executeSqlScript() now accepts a JDBC Connection;
JdbcTestUtils, AbstractTransactionalJUnit4SpringContextTests, and
AbstractTransactionalTestNGSpringContextTests now use
DatabasePopulatorUtils to execute a ResourceDatabasePopulator instead
of executing a script directly via ScriptUtils.
- Introduced JdbcTestUtilsIntegrationTests.
Issue: SPR-9531
Prior to this commit neither ResourceDatabasePopulator nor
JdbcTestUtils properly supported multi-line comments (e.g., /* ... */).
Secondarily there has developed a significant amount of code
duplication in these two classes that has led to maintenance issues
over the years.
This commit addresses these issues as follows:
- Common code has been extracted from ResourceDatabasePopulator and
JdbcTestUtils and moved to a new ScriptUtils class in the
spring-jdbc module.
- Relevant test cases have been migrated from JdbcTestUtilsTests to
ScriptUtilsTests.
- ScriptUtils.splitSqlScript() has been modified to ignore multi-line
comments in scripts during processing.
- ResourceDatabasePopulator supports configuration of the start and end
delimiters for multi-line (block) comments.
- A new test case was added to ScriptUtilsTests for the new multi-line
comment support.
Issue: SPR-9531
This change removes the use of a CountDownLatch to wait for the
asynchronously computed controller method return value. Instead we
check in a loop every 200 milliseconds if the result has been set.
If the result is not set within the specified amount of time to wait
an IllegalStateException is raised.
Additional changes:
- Use AtomicReference to hold the async result
- Remove @Ignore annotations on AsyncTests methods
- Remove checks for the presence of Servlet 3
Issue: SPR-11516
This commit introduces a new isInJavaLangAnnotationPackage(Annotation)
method in AnnotationUtils. This method is now used in AnnotationUtils,
AnnotatedElementUtils, and MetaAnnotationUtils to ensure that search
algorithms do no search for meta-annotations on annotations in the
"java.lang.annotation" package.
The following are some empirical results from this change:
- The number of times that the findAnnotation(Class,Class,Set) method in
AnnotationUtils is recursively invoked while executing
AnnotationUtilsTests drops from 51 to 29.
- The number of times that the process(AnnotatedElement) method in
AnnotationUtils.AnnotationCollector is recursively invoked while
executing AnnotationUtilsTests.getRepeatableFromMethod() drops
from 16 to 2.
- The number of times that the doProcess() method in
AnnotatedElementUtils is recursively invoked while executing the
"getAnnotationAttributes() On MetaCycleAnnotatedClass with missing
target meta-annotation" test in AnnotatedElementUtilsTests drops
from 23 to 5.
- The number of times that the findAnnotationDescriptor(Class,Set,Class)
method in MetaAnnotationUtils is recursively invoked while executing
the "findAnnotationDescriptor() on MetaCycleAnnotatedClass with
missing target meta-annotation" test in MetaAnnotationUtilsTests drops
from 16 to 8.
Issue: SPR-11483
Prior to this commit, the following methods in ContextLoaderUtils
treated a composed @ContextConfiguration annotation (i.e., a custom
annotation that is meta-annotated with @ContextConfiguration) as the
"declaring class" instead of the actual test class.
- resolveContextConfigurationAttributes()
- resolveContextHierarchyAttributes()
As a consequence, if @ContextConfiguration is used as a
meta-annotation, the meta-annotated class is stored as the
"declaringClass" in ContextConfigurationAttributes. Thus, when a
ContextLoader (or SmartContextLoader) attempts to detect default
resource locations or configuration classes, it does so for the
composed annotation class instead of for the declaring test class.
This commit ensures that ContextLoaders are supplied the declaring test
class instead of the composed annotation class in such use cases.
Issue: SPR-11455
Prior to this commit, the findAnnotationDescriptor() and
findAnnotationDescriptorForTypes() methods in MetaAnnotationUtils only
supported a single level of meta-annotations. In particular, this kept
the following annotations from being used as meta-annotations on
meta-annotations:
- @ContextConfiguration
- @ContextHierarchy
- @ActiveProfiles
- @TestExecutionListeners
This commit alters the search algorithms used in MetaAnnotationUtils so
that arbitrary levels of meta-annotations are now supported for the
aforementioned test-related annotations.
Issue: SPR-11470
Prior to this commit, if @ActiveProfiles were used as a meta-annotation
on a composed annotation, then the composed annotation's class would be
passed to the ActiveProfilesResolver.resolve() method instead of the
test class, which breaks the contract for ActiveProfilesResolver.
This commit addresses this issue by ensuring that the actual test class
is always passed to ActiveProfilesResolver.resolve().
Issue: SPR-11467
mimeType is not a valid method on ContentResultMatche.
I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
equalTo is not a valid method on JsonPathResultMatchers
I have signed and agree to the terms of the SpringSource Individual Contributor License Agreement.
Prior to this commit, a NoClassDefFoundError caught in
TestContextManager's retrieveTestExecutionListeners() method would be
handled differently for implicit default listeners (i.e., listeners not
declared via @TestExecutionListeners) and listeners explicitly declared
via @TestExecutionListeners. Specifically, a NoClassDefFoundError would
cause a test to fail for an explicitly declared TestExecutionListener
but not for an implicitly declared one.
This commit addresses this issue by:
- Always swallowing a NoClassDefFoundError for both implicitly and
explicitly declared TestExecutionListeners.
- Changing the log level from DEBUG to INFO to make such situations
more visible to the average end user.
Issue: SPR-11347
The ServletTestExecutionListener is now prepended to the set of default
listeners in AbstractJUnit4SpringContextTests and
AbstractTestNGSpringContextTests.
Issue: SPR-11340
This commit makes the logging in TransactionalTestExecutionListener
consistent for both starting and ending transactions. Specifically,
the current TestContext is now included in the informational log
statement when starting a new transaction.
Issue: SPR-11323
When adding headers generically, MockHttpServletRequestBuilder now
recognizes Content-Type and updates the contentType field accordingly.
Issue: SPR-11308
This change splits out an abstract base class from DefaultMockMvcBuilder
with StandaloneMockMvcBuilder switching to extend the new abstract class
(rather than DefaultMockMvcBuilder).
Issue: SPR-11238
- Completed Javadoc for MetaAnnotationUtils.
- Added Javadoc notes to multiple annotations in the TCF, pointing out
which annotations can be used as meta-annotations.
Issue: SPR-11109
This commit fixes a bug introduced in the last commit.
ServletTestExecutionListener (STEL) now tracks whether it has already
populated the RequestContextHolder.
Issue: SPR-11144
The previous commit for issue SPR-11144 revealed a bug in
ServletTestExecutionListener (STEL). Specifically, STEL acted on the
fact that the ApplicationContext for a given TestContext was an
instance of WebApplicationContext. This behavior could potentially
break test code from previous releases of the Spring Framework that
relied on a custom setup of the RequestAttributes in the
RequestContextHolder with a custom WebApplicationContext ContextLoader.
This commit addresses this issue by ensuring that STEL only comes into
play if the test class is annotated with @WebAppConfiguration (for
prepareTestInstance() and beforeTestMethod()) or if the TestContext
attribute named RESET_REQUEST_CONTEXT_HOLDER_ATTRIBUTE is set to
Boolean.TRUE (for afterTestMethod()).
Issue: SPR-11144
Prior to this commit, the ServletTestExecutionListener did not
overwrite RequestAttributes in the RequestContextHolder if the
ApplicationContext associated with the given TestContext was not a
WebApplicationContext; however, the ServletTestExecutionListener would
clear the RequestAttributes after every test method execution,
regardless of whether the context was a WebApplicationContext or not.
This behavior breaks backwards compatibility with integration tests
that managed the RequestAttributes in RequestContextHolder themselves.
This commit addresses this issue by introducing a TestContext attribute
named RESET_REQUEST_CONTEXT_HOLDER_ATTRIBUTE in
ServletTestExecutionListener. This attribute is used internally within
ServletTestExecutionListener to ensure that the RequestContextHolder is
only cleared (i.e., reset) if the ServletTestExecutionListener actually
populated the RequestContextHolder.
Issue: SPR-11144
Juergen Hoeller
Sam Brannen
Rossen Stoyanchev
Sebastien Deleuze
cbaldwin74
Anton Bobov
hupfis
Greg Turnquist