Convenient superclass for tests that should occur in a transaction, but normally
will roll the transaction back on the completion of each test.
This is useful in a range of circumstances, allowing the following benefits:
Ability to delete or insert any data in the database, without affecting other tests
Providing a transactional context for any code requiring a transaction
Ability to write anything to the database without any need to clean up.
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
transactional context.
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
torn down.
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.
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 transactional context.The
startNewTransaction()method may be called after a call toendTransaction()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, unlesssetComplete()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 torn down.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.