Database

When the JUnitRecorder is recoding a database there are several side effects when trying to record. They differ a little from technology in use.

JDBC

The basic problem are transactions. It is no use to just open a second connection to the database and store a snapshot when entering the target method an when leaving. Because there are (most times) transactions involved, the second connection might not see all changed data and therefore wrong data are recorded.

This means beside providing a TracerListener for the JUnitRecorder it is also necessary to implement a way the Database recorder can 'reuse' the same connection as the original code.

The recoding and later testing is implemented with the help of the DBUnit library. Therefore the Listener was named DBUnitListener. A DBUnitListener uses to retrieve the concrete connection a delegation to an IConnectionProvider.

Currently no general JDBC Provider is implemented, cause plain JDBC is extremely dependent on the project.

Spring / Hibernate / JPA

In most projects you'll not directly use JDBC, instead an OR-Mapper will be used. For Hibernate a ConnectionProviderSpingHibernate is implemented. When you use this provider for the Database connection you only need to add an additional spring-bean "com.seitenbau.testing.addons.spring.dbunit.SpringConnectionDataSourceInjectorBean" to your spring Configuration.

Spring has the advantage that the connection is stored in a central position. This is why the provider is so easy to use.