At some point in the unit testing game you will need to tackle the unpleasant task
of actually coding and running unit tests on the data access code. This in itself
can open a bit of a can of worms - the bigger the database, the more worms you need
to deal with. If you want a quick solution to being able to run a bunch of data
access tests that insert, update and delete data in tables - try putting a TransactionScope object
at the test fixture level. If the scope is not committed the changes are not stored,
perfect scenario for a group of unit tests.
Marcus Rosen prompted the idea and
I have been using this technique against a local copy of an MSSQL database
and have had no issues to date. It has simplified the development process in that
data does not keep disappearing due to my unit tests clearing tables and inserting
test items.
I have seen "Rollback" attributes around (such as http://weblogs.asp.net/rosherove/archive/2004/10/05/238201.aspx)
but the above solution is a one liner and requires no new libraries, and
integration etc.
I like a simple solution ;-)
MSDN TransacrionScope Help:
http://msdn2.microsoft.com/en-us/library/system.transactions.transactionscope.aspx
Subscribe