Yep, I came from stackoverflow although I have had your feed on my GoogleReader for some time already (forgot via which article).

Great blog! I do hope that we find the answer for that question one day.

@Jon: Welcome to the blog (no doubt you came from StackOverflow eh? ) Thanks for the comment. There are some nifty features of the unit testing frameworks which do help clean things up, but the question still remains: should we be doing it anyway!

Quite nifty, although it’s gonna mess a lot with incremental/Identity-keyed tables.

You know I am big fans of you both, its nice for us to debate like this. Reminds me of the good ol’ days
Rob, I can totally see the merits of adding all the CRUD operations in one test, if you use this kind of tranny method it may save you having to hand pick the DB clean if a test fails though.

Maybe this bit of pseudo code would explain the solution I proposed a bit better, I don’t think I gave it a good enough of an attempt last time. I don’t think it is touched by the don’t use Setup or Teardown rules.

using System.Transactions;
using NUnit.Framework;
using System.Data.SqlClient;
 
public class TestWithTransaction
{
  [TestFixtureSetUp]
  public void TestSetup ()
  {
    Transaction.Current = new Transaction();
  }
 
  [TestFixtureTearDown]
  public void TearDown()
  {
    Transaction.Current.Rollback();
  }
}
 
[TestFixture]
public class NormalTest: TestWithTransaction
{
  [Test]
  public void AtoB ()
  {
    CustomerRepository.DoSomething();
  }
}
 
public class CustomerRepository
{
  public static void DoSomething()
  {
    //So if we do not have a current
    //distributed Tranny we can start one.
    if (Transaction.Current == null)
      Transaction.Current == new Transaction()
 
    // now we will have a transaction local
    //to here or a distributed one with several
    //command tied up in it.
    SqlConnection connection = new SqlConnection("")
    connection.EnlistDistributedTransaction(
    Transaction.Current);
  }
}

Never knew you had a blog Rob, send me the url, always interested to hear what you are thinking.

Oj, Yeah totally agree with your point about having stuff like nested trannies and it degrading test performance. If you have this kind of setup above you can dig yourself that hole quite easily.

I think it is pretty useful if you are doing some vanilla Db work and want a nice sandbox for your tests to play in.

One problem with this method is though that if you do not have you data access object setup like this for handling transactions then you will have to change your underlying code to support this which breaks a few rules. And therefore that is where Robs solution of all the CRUD in one test makes perfect sense.

The way I see it, (as in my example in the article) is that if I’m going to write the code to create, and the code to delete – I may as well use them together in the unit test since I’m already breaking some unit testing rules, in which case – I’ve written no extra code that is purely for the unit test.

In addition, I don’t use Setup or TearDown anymore because I rather keep the production code DRY, but my tests MOIST for ease of maintenance…

I can write some new articles about all those concepts too – including what I do when it’s not a PHYSICAL delete, but rather a LOGICAL delete. Doesn’t seem there’s much interest there though – but we’ll see.

Cheers,
Rob

I can’t see why it wouldn’t be compatible with Linq?

Nice post. I couldn’t agree more on your points on the posts on here and the other blog. It is sometimes a lot easier to stay in the world of theory rather than down at the coal face, at the ‘business end’ as I call it.

Had this problem myself before and saw a solution implemented by a team I joined for this problem in the System.Transactions namespace.

Basically I think that a TransactionScope was setup on TestFixtureSetup, all the data calls were enlisted into that and then the TransactionScope was rolled back on TestFixtureTearDown, this gave the testing a safe kind of ‘sandbox’ to play in.

So this could give a solution to the whole ‘what if one fails problem’, as it is in one big trannie.

Whether this is compatible with linq I am not too sure though.

Interested to hear your thoughts on this.

Yup, I’m whinging about relatively minor stuff. But at the end of the day, the cost of maintenance should be kept low and having unit test code attempt to cover more than the unit level increases that cost.

Thanks for the comment

One thing that I have done for this scenario is to have the test fixture class have a helper class that is a private member of the test fixture. The helper class knows how to delete items of type x, and anything that references those items. The helper class is responsable for cleaning up after the created db rows. Preferably the cleanup code goes directly to the database.

CustomerHelper {
 List<int> ids;
 public void AddToDeleteList(int value) { _ids.Add(value) };
 public void Cleanup() {
 if( !ids.Any() ) return;
 
 // execute some sql that uses an IN clause. execute all the sql at once.
 string sql = string.Format( "delete from tablex where tablexid in {0}",
                      ids.ToCsv() );
 
 try { db.Execute(sql); } catch ...
 ids.Clear();
}

The testfixture then holds reference to the helper that it needs, and executes the helper in the test fixture teardown. Don’t put these inside the test method itself, because the test can fail, and we want to ensure the db will be cleaned up if at all possible. By adding the helper to the test fixture level, you can not only have simple cruds, but any number of test methods can add to the delete list, content that the new object will be deleted.

private CustomerHelper _customerHelper;

Inside the test method, immediately after the first update() you store the id for later deletion.

_customerHelper.AddToDeleteList(newId);

You can definitely make this more robust, but that’s the essence of it all. One of the other reasons this is done is so that certain configurations can be constructed in the db and later cleaned up. No more relying that test code ‘knows’ that ID 1234 is a Manager, and ID 3456 is a graduate employee. Your test creates entities in the database and cleans them up for you.

Also, typically, you assign a specific category to the test (ie DBIntegration) and only run those daily, because they do take a long time to run, but a daily test by Cruise is better than no run at all.

* I’m tempted by IDisposable for the helper class, but can I guarantee that the db is still legitimate when IDisposable is called? Maybe IDisposable as a tracking method, then at least you know if the teardown never happened and can log that somewhere.