I have to slightly disagree with Gary. How would you then run an automated unit test without having to manually update your test data each time? For example, say your unit test inserts “Johh Doe” with a Client_Insert proc. Let’s say your unit test then runs a read to make sure the insert was successful, and you have to test if “John Doe” now exists. No matter what specifically you test, you would have to update the test manually before you can run it again.

Additionally, you can still test your CRUD operations AND use transactions. Why not run whatever you are testing (say, an insert), and then run a read operation to verify, inside the same transaction scope? That way, you can fully test your CRUD operations, while still having the flexibility to roll it back when the test is complete.

I personally like to separate my Database Unit Tests from Data Access Unit Tests.. meaning that I won’t test my CRUD operations in the same unit test that is testing something like a DAO.

Great article Chinh Do!

Strictly speaking your appraoch above is not for Unit Tests, but can be more closely attributed to Integration Tests.