Friday, April 16, 2004

Working on a database application, the urge for testing of database has appeared. Unfortunaltely, there are no real framework that can tackle this problem (real means with specialized assertion and fixtures). Unit test framework like NUnit are too simplistic to provide such functionality.

A little hope: I have run into this nice article which gives an introduction about database testing. The author gives a good methodology to set up a test framework for database:

    1. Separate production database from test database
    2. The test fixture must empty the tables of the test db befure launching the runs 
    3. do small unit tests using the business objects.

 There is one big gotcha about this: usually database are run in an "heavy" multithreaded environment and, in testing, we would like to detect locks and so on. The Unit test approach is too gentle :). I'll come back on this problem later (with somes solutions hopefully).

posted on Saturday, April 17, 2004 3:22:00 AM UTC  #    Comments [2]
Tracked by:
"votivo" (online) [Trackback]
Monday, June 06, 2005 6:15:35 PM UTC
I will be releasing a version of a factory based database helper (<a target="_new" href="http://sourceforge.net/projects/snapdal">http://sourceforge.net/projects/snapdal</a>) that included DotNetMock and a framework for having your database calls get mock objects instead of sql command/readers and the like. This way you can test your database driven code without so many unnatural acts. The early release has been sent out to a few people and with good results, I let it go this week.
<br>
<br>I don't think unit tests have to be too gentle, and this code would allow you to inject mock sql execptions, deadlocks and the like.
Philip Nelson
Monday, June 06, 2005 6:15:36 PM UTC
This is very interresting, I will monitoring your package for the new version with DotNetMock.
Jonathan de Halleux
Comments are closed.