Static dependency exit strategy

Question

The project that I have just joined uses the command pattern quite extensively for handling calls into the business logic layers of the project.

The business logic layers are built as static handlers calling into providers. The commands then call into these static handlers.

The team want to improve test coverage, and I would like us to move more toward true TDD but the use of static handlers means that there is a hard coded dependency in the commands and there is no way to inject the handlers as dependencies and so it is very difficult to unit test the commands in isolation.

Does anyone have any good suggestions for a strategy for us to move toward a more testable command pattern bearing in mind that there are a lot of commands already in use.

The process method below would be called when execute is called on the command. This would be the method under test. This is a typical example of the usage of static handlers in the command classes.

protected override bool Process()
{
    this.user = SecurityHandler.ActivateUser(this.activationGuid);
    bool success = this.user != null;

    if (!success)
    {
        this.AddStatusMessage(StatusMessageType.Error, "/Commands/Security/ActivateUserCommand/IncorrectLink", true);
    }

    return success;
}

Answer 1

Dependecy Injection (Inversion of control)

Static dependencies are bad smell, and usually one can use DI/IoC to remove that bad smell. Find any DI/IoC framework you like and use it.

Answer 2

Static methods/fields generally hurt with testability - because it introduces the risk of tests not being isolated. One test could set some static field, changing the initial state for test2.

That said there was nothing in the Command Pattern that needed static handlers.. so I think it's a custom implementation. I would like to see some sample code for a shorter answer.

There is no easy way out.. move the static parts into another class/object and pass it into the objects that need to access it. This might mean adding a parameter to methods that are currently using a TypeName.StaticField invocation to get at the data.

Update (for posted code snippet): I fail to see the Command Pattern here.. anyways to get the method under test.

• Does the SecurityHandler.ActivateUser have any side-effects ? Does calling it the second time differ in any manner from calling it the first time? If not (i.e. it is a pure service call) then dont worry about it.
• if ActivateUser has some side-effects, then you have to do some work. i.e. Turn the static methods into instance methods and pass in an instance of SecurityHandler to the containing type of Process(). You can either pass it in as a method parameter to Process() or a ctor/property set on containing type. Choose whatever you feel is apt.

Answer 3

Although this doesn't help in terms of design patterns, if you want to increase testing now you could always use something like Typemock Isolator or Telerik JustMock, which allow you to mock out static classes, while you convert your code away from the current design. (These are commercial products).

I wouldn't do that myself though, as there's a danger you'll just start relying on them and not bother refactoring your code to make it testable - one of the things I like about TDD/automated testing is that it forces you to have code which is loosely coupled and follows some good design principles, and tools like these can take away from that.