This is useful in a range of circumstances, allowing the following benefits:
This class is typically very fast, compared to traditional setup/teardown scripts.
If data should be left in the database, call the setComplete()
method in each test. The "defaultRollback" property, which defaults to "true",
determines whether transactions will complete by default.
It is even possible to end the transaction early; for example, to verify lazy
loading behavior of an O/R mapping tool. (This is a valuable away to avoid
unexpected errors when testing a web UI, for example.) Simply call the
endTransaction() method. Execution will then occur without a
The startNewTransaction() method may be called after a call to
endTransaction() if you wish to create a new transaction, quite
independent of the old transaction. The new transaction's default fate will be to
roll back, unless setComplete() is called again during the scope of the
new transaction. Any number of transactions may be created and ended in this way.
The final transaction will automatically be rolled back when the test case is
Transactional behavior requires a single bean in the context implementing the
PlatformTransactionManager interface. This will be set by the superclass's
Dependency Injection mechanism. If using the superclass's Field Injection mechanism,
the implementation should be named "transactionManager". This mechanism allows the
use of this superclass even when there's more than one transaction manager in the context.
This superclass can also be used without transaction management, if no
PlatformTransactionManager bean is found in the context provided. Be careful about
using this mode, as it allows the potential to permanently modify data.
This mode is available only if dependency checking is turned off in
the AbstractDependencyInjectionSpringContextTests superclass. The non-transactional
capability is provided to enable use of the same subclass in different environments.