   SQL rollback in C# for unit testing
  Here is my situation, I am developing tests for application that uses SQL as a database. What I want is clean database for each test so I want to rollback any changes made to database during tests.Since I am accessing application's presentation layer, can I connect to database, set some flag, perform the test and undo any operation that I did? Will there be concurrency issues?I am using NUnit for unit testing.   
  You aren't doing this on a production database, are you?In general, you'd want a clean database. Then you populate it with necessary entries, run the actual test, and drop the database.But running any kind of unsafe (by definition) data-altering mechanism on a production database is simply a thing to lose the job over, and get yelled at.   ;  No, I have special database with known data, not production database. Problem is that restoring database for each task can be tedious and I want to know is there a simpler solution like rollback.   ;  Why is it tedious?  Your application should creating the schema.  How do you set up the initial database when the user installs your software, and how do you upgrade an existing database when the schema changes in a later version?  Surely you aren't doing this manually?   ;  As Antheus mentioned, messing with a production database isn't advisable in general. Though everyone is doing it all the time and there are ways to effectively minimise possible problems.Anyway, how about putting your fixtures in transcation? I'm not the chap in our company doing this, but I guess something like Simplified Database Unit testing using Enterprise Services by Roy Osherove is the way to go.   ;Quote:Original post by Toni PetrinaHere is my situation, I am developing tests for application that uses SQL as a database. What I want is clean database for each test so I want to rollback any changes made to database during tests.Since I am accessing application's presentation layer, can I connect to database, set some flag, perform the test and undo any operation that I did? Will there be concurrency issues?I am using NUnit for unit testing.If your database code doesnt break out of transactions explicity you can wrap all your code in a transaction scope and just never commit it.using (TrasactionScope s = new TransactionScope){   //calls to your presentation layer here}//the transaction with all (except things like drop database and other..) database operations will be rollbacked here.The TransactionScope is in the System.Transactions namespace.   ;Quote:Original post by Toni PetrinaNo, I have special database with known data, not production database. Problem is that restoring database for each task can be tedious and I want to know is there a simpler solution like rollback.Drop entire database on beginning of every test, populate it.That part needs to be fully automated. In addition, you need to verify that database gets cleaned up properly. Assuming anything in unit tests makes them mostly redundant.The above process may take some time, but in general, you shouldn't be populating millions of rows for every test. Tests are about units, small packages, testing single functionality.Another approach is to use mock objects (see google). Those allow you to minimize interaction with a database, and only require you to test basic functionality, in case of various ORM solutions, even that isn't needed, since they'll provide you with some form of a test harness.   ;  @Naurava kulkuri and @vibloI've seen that, problem is that I am testing presentation layer and I don't have information about current transaction, it is hidden inside another dll. So, breaking transaction doesn't help since my code doesn't touch anything.What I am testing is ASP.NET project and it's functionality so either I have to recreate database before every test (I am using Watin for unit tests) or I can somehow rollback changes in teardown method.   ;Quote:Original post by AntheusDrop entire database on beginning of every test, populate it.That part needs to be fully automated. In addition, you need to verify that database gets cleaned up properly. Assuming anything in unit tests makes them mostly redundant.The above process may take some time, but in general, you shouldn't be populating millions of rows for every test. Tests are about units, small packages, testing single functionality.Another approach is to use mock objects (see google). Those allow you to minimize interaction with a database, and only require you to test basic functionality, in case of various ORM solutions, even that isn't needed, since they'll provide you with some form of a test harness.Mock objects are out of the question since I am testing web pages, not code directly. I'll try repopulation method.   