Question

I have a project in which I am using .nettiers generated code as my DAL.

At the moment, my tests consist of physically setting up test data in the database for each test, then allowing the nettiers objects to hit the database and return as required.

Obviously, this isn’t particularly efficient and so far my 250 odd tests take about 10 minutes to run, so I’ve been looking into adding mocking into my tests.

While I’m pretty sure I understand the concepts of mocking out the database calls, I’m having trouble applying it to nettiers in particular, since it’s fairly strongly coupled to the database.

One of the methods I want to test looks like this (cut down slightly for brevity’s sake):

public class InterfaceManagerService
{
    public DataDocument SaveDataDocument(DataDocument entity)
    {
        var lookupEntity = DataRepository.DataDocumentProvider.GetByDocumentId(entity.DocumentId);
        if (lookupEntity == null)
        {
            File fileEntity = new File();
            fileEntity.Name = entity.Name;

            var savedFileEntity = DataRepository.FileProvider.Save(fileEntity);

            entity.FileId = savedFileEntity.FileId;

            var savedEntity = DataRepository.DataDocumentProvider.Save(entity);

            return (savedEntity);
        }             
    }
}

Currently, I’m using a trial version of Typemock, since that appears to do what is required, but I’m open to any alternatives, particuarly open source ones.

The first problem I run into it working out if I should be creating a mocked instance of InterfaceManagerService, or of the DataRepository, or the Entities themselves (nettiers entities do have an interface that might be useful).

The second problem is, how to create the fake object that is to be returned, since nettiers puts a bunch of extra properties into the entities that would result in large and unwieldly tests if I create a fake instance of each object I’m expecting.

I guess ultimately, I’m looking for some direction in the best way to write unit tests for methods that use nettiers data repository methods, but to avoid hitting the database, since there doesn’t appear to be much about it on the internet currently.

Answer 1

I’m going to give some suggestions derived from my personal experience. While these may not address all of your concerns, I hope that they will at least be of some help to you.

• Rhino Mocks is a fairly well-known mocking framework. If you are looking for an alternative to Typemock, I’d suggest that.

• Regarding whether to mock the InterfaceManagerService or the DataRepository, I’d say that it depends on what you’re trying to test. Do you want to test the InterfaceManagerService? Then you would want to create mock objects for the DataRepository.FileProvider and DataRepository.DataDocumentProvider. If you are not already familiar with the concept of “dependency injection”, then look into that; it looks like you should apply some dependency injection to your InterfaceManagerService class (assuming that you want to unit test it).

  If you want to unit test code that consumes the InterfaceManagerService, then just mock the InterfaceManagerService.

… how to create the fake object that is to be returned, since nettiers
puts a bunch of extra properties into the entities that would result
in large and unwieldly tests if I create a fake instance of each
object I’m expecting.

• Writing a single unit test is easy. Writing many unit tests to cover all of the scenarios that you need to cover, and doing so in an efficient manner that does not result in much code being duplicated throughout your unit tests is difficult, especially when the inputs and outputs of the method being tested are complex.

  For this I don’t have much guidance, other than to say that my personal approach is to try to consolidate test initialization logic and test verification logic in order to avoid a lot of code duplication, but at the same time I try to avoid making the unit testing code itself so complicated that it becomes difficult to understand and prone to bugs.

  In general, I think that I end up dividing test logic into 3 categories: inputs/initialization, expectations, and results/verification. I’ve found that putting the logic into these 3 categories was helpful for me in being able to consolidate the common code across unit tests.

  Die-hard test-driven development proponents would likely say that struggling to produce a clean set of unit testing code is an indication of a design flaw in the application. I’m not going to disagree with that, but I will say that, unfortunately, the projects that I’ve been involved with have not generally produced a unit testing code base that was both simple and thoroughly comprehensive. The simple unit tests generally didn’t really explore problematic scenarios, and the comprehensive unit tests generally required a lot of test setup logic.