Question

I’m writing some Unit tests against a database, and we’re using transactions to make sure that our test data gets removed at the end.

I’m running into a problem where methods that I’m testing are using their own TransactionScope objects, and it seems to be blocking when hitting the database.

This is inside my test’s base class:

BaseScope = new CommittableTransaction(new TransactionOptions() { IsolationLevel = IsolationLevel.ReadUnCommitted, Timeout = new System.TimeSpan(0, 5, 0) });

and then inside the method I’m testing, it does:

using (TransactionScope scope = new TransactionScope())

The first time that the code inside the 2nd scope their touches the database, it hangs. Do I have any way around this problem?

Answer 1

If you are using a Database then you are not doing Unit testing, and the problems you are experiencing are one of the reason why true Unit testing uses Mocks and Stubs.

Now the tests you are doing are very valuable, and in some cases I would actually do them instead of Unit Testing. I label this Early Integration Testing (EIT). The key point here is that we find a whole new class of bugs when working with the real thing not the Unit Test mocks. And the key here is Real Thing. As soon as you fake up the environment with artifical transaction scopes etc. you are losing much of the benefit of EIT because you don’t catch subtle interaction errors, or (as in your case) introduce artificial problems.

I would find a way to quickly populate the database with sufficient test data, and restore it to that state outside the test. A “reset to known state” script is very helpful for these kind of tests.