Question

I’m in the midst of rewriting a database application and using Entity Framework to access the DB. Currently I am using MSTest and a copy of the underlying database as part of these tests. My MSTest involves the following code as part of each test:

    [TestInitialize()]
    public void MyTestInitialize()
    {
        transScope = new TransactionScope(TransactionScopeOption.RequiresNew, new TransactionOptions { Timeout = new TimeSpan(0, 10, 0) });
    }

    [TestCleanup()]
    public void MyTestCleanup()
    {
        Transaction.Current.Rollback();
        transScope.Dispose();
    }

Now, this seems to work pretty well for testing and resets the DB between tests. My tests use the DB context to do CRUD operations against the test DB and then roll them back afterward.

I’ve read a bit about isolating the C# library from the underlying DB for testing but I’m wondering what this actually buys me. As part of this rewrite, most (but not all) of the code that was in stored procedures has been moved in the C# layer but a few remain which are called via triggers on tables. What do I gain from going through the exercise of mocking out that database layer? Frankly, when I look at doing this, it seems like a lot of additional work without any obvious value, but perhaps I’m missing the point here.

Thoughts?

Answer 1

It depends on the the kinds of tests you are writing. When writing unit tests where you want to test one unit of code–typically a class–then usually it’s good for two things to hold true:

• The tests should run as fast as possible. Meaning 100’s of tests per second.
• The code you are testing should be isolated from other code such that you can control the way dependencies work and test different kinds of inputs and outputs easily.

Both of these things are difficult to do if you use a real database for all tests. The first because a round-trip to the database usually takes a lot more time than just running some code. The second because you need to have your database setup with lots of different kinds of data, including negative cases and corner cases, and sometimes even make the database fail. It’s often easier to instead mock the dependencies of your class and pass in any inputs needed.

That being said, I have written many tests that use a similar pattern to the one you describe and they work well and run relatively fast. Personally, I would use a combination of real unit tests without a database, and tests like the ones you have that are more like functional testing of a component.

In the end, do what works for you.