Specification Pattern Unit Tests

Question

We have recently adopted the specification patterns for validating domain objects and now want to introduce unit testing of our domain objects to improve code quality.

One problem I have found is how best to unit test the validate functionality shown in the example below. The specification hits the database so I want to be able to mock it but as it is instantiated in-line I can't do this. I could work off interfaces but this increases the complexity of the code and as we may have a lot of specifications we will ultimately have a lot of interfaces (remember we are introducing unit testing and don't want to give anyone an excuse to shoot it down).

Given this scenario how would we best solve the problem of unit testing the specification pattern in our domain objects?

...
public void Validate()
{
    if(DuplicateUsername())
    { throw new ValidationException(); }
}

public bool DuplicateUsername()
{
    var spec = new DuplicateUsernameSpecification();
    return spec.IsSatisfiedBy(this);
}

Answer 1

You could extract getDuplicateUsernameSpecification() into a public method of its own, then subclass and override that for your tests.

Answer 2

A more gentle introduction of Seams into the application could be achieved by making core methods virtual. This means that you would be able to use the Extract and Override technique for unit testing.

In greenfield development I find this technique suboptimal because there are better alternatives available, but it's a good way to retrofit testability to already existing code.

As an example, you write that your Specification hits the database. Within that implementaiton, you could extract that part of the specification to a Factory Method that you can then override in your unit tests.

In general, the book Working Effectively with Legacy Code provides much valuable guidance on how to make code testable.

Answer 3

If you use IoC then you can resolve the DuplicateUsernameSpecification and in test mockup the last one

Edit: The idea is to replace direct constructor call with factory method. Something like this:

public bool DuplicateUsername()
{
    var spec = MyIocContainer.Resolve<DuplicateUsernameSpecification>();
    return spec.IsSatisfiedBy(this);
}

Answer 4

If you dont want to do constructor injection of a factory, and make the specs mockable... Have you considered TypeMock? It is very powerful for dealing with this sort of thing. You can tell it to mock the next object of type X that is to be created, and it can mock anything, no virtuals etc required.