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