Writing unit tests for any application that connects to a database is always challenging, because deviation from the expected alterations of the database may influence the work of the business objects. The same tests have to run over and over again – after each change of the code, in order to ensure that the previous functionality has not been broken by the newly introduced changes. Altering the data so many times may have unpredictable consequences.

One of the most popular solutions of that problem in the Java and .NET worlds is the usage of mocking framework, for example Rhino Mocks. And despite the enormous advantages of this approach it has also some noticeable drawbacks. For example it is not hard to imagine a situation where your tests will pass well with the mocked data but will fail on the real database. And what if you have a lot of business logic in stored procedures that also need to be tested?