DbUnit how to guard against multiple tests running at the same time?

Question

I am working on a test environment for a project, and am looking into using DbUnit.NET to do a lot of the database interaction testing. I do have one very big question though:

We are running against Oracle, and setting up a seperate test DB instance for every developer really isn't feasible (especially since we only have 1 DBA who is already strapped for time). This means that all developers and out Continuous Integration server all need to use the same DB schema.

So, on to the question: is there a good way to prevent more than 1 person from testing at the same time? It would be easy to put a record in a db table that indicates that a test is running, then remove it after tests are finished, but NUnit doesn't have any way to run something at test session start and end.

Any other thoughts? It seems like it should be a pretty common issue... or does everyone actually run separate DB instances for every developer/tester that might run the tests?

Answer 1

You can use the [TestFixtureSetUp] attribute to inject your flag that indicates that tests are running as a way to simulate a "true" semaphore.

Answer 2

We used a dummy table with a single record as a lock token when we ran database tests for a bunch of developers on a shared database. We actually acquired the lock for each test case individually so that a developer who wants to run one test case doesn't have to wait for another developer who's running the whole suite to finish. We made each test set up its own data - no carry over between test methods.

We used the database locking mechanism to actually queue tests instead of failing when someone else is already running a test. I think Oracle's locking algorithm is a little different, so I don't know how that would work.

The only place we ran into trouble was when a developer wanted to step through a test in debug mode. That would block any other developers who wanted to run a test until he released the debugger. We wrote the current user's name into a dummy table, and had the locking mechanism print a message if it got blocked for more than 30 seconds: "Bob is currently running a test and has been for the last 5 minutes."

This was OK, but it was a lot of work to maintain. We tried to keep the number of database tests small, and do most of our tests as pure unit tests in memory.

Answer 3

Something I did in a problem with some similarities to this one:

The program had a configuration variable that was added to the front of all relevant items. Each station had it's own setting, properly set there would be no conflicts.