TDD in SharePoint – Introduction to common vocabulary

This post is part of a series on Test Driven Development – Using Dependency Injection

There are a number of terms that you are likely to hear very early on in your journey to Test Driven Development, these terms generally refer to specific patterns of coding that have developed to support particular problems.  You should be familiar with terms like Singleton and Factory which are used as a common vocabulary and help developers to communicate their design.

In order to complete the refactoring of our project we will introduce some new terms Loosely Coupled, Dependency Inversion, Dependency Injection and Inversion of Control to help us describe the changes and the reasoning behind them.

Loosely Coupled

Coupling refers the relationship between two modules. In a loosely coupled relationship the modules relate to each other through a common interface and are not concerned with the other modules internal implementation. Changes to one module does not require a change in the implementation of the other; one of the benefits of this loose coupling is that it makes testing easier, it allows us to replace the real modules with fake ones during testing. The fake modules will implement the same common interface allowing the module under test to work without any changes.

In order to be able to achieve this loose coupling we need to implement the Dependency Inversion principle.

Dependency Inversion

The Dependency Inversion principle is used to ensure your code is loosely coupled and therefore more testable. Often people will not mention this instead they will refer to Inversion of Control or Dependency Injection, described below, however when dealing with Unit Testing Dependency Inversion is really at the heart of what we are doing.

In simple terms dependency inversion means we flip things so that the calling code is the one that decides which implementation will be used, hence ‘inversion’.

In order to achieve this we use Dependency Injection.

Dependency Injection

This really is a grand term for what is a very simple concept a way of providing an object with the variables it needs.

Dependency Inversion = give the calling code control over which variables are used

Dependency Injection = a way to pass those variables into the object

An example here will probably help, the code sample shows how the Sample object (class) defines and instantiates the RandomNumber object (class)

public class Sample
{
    private RandonNumber _randomNumber;
    public Sample()
    {
        _randomNumber = new RandomNumber();
    }
    public string GetRandomMessage()
    {
        ...
        int messageId = _randomNumber.GetRandomNumber(itemCount);
        ...
    }
}

This example is tightly coupled as the Sample object explicitly creates the RandomNumber object that is then uses internally, the code below demonstrates how we have refactored this to use the Dependency Injection pattern and enable loose coupling.

public class Sample
{
    private RandonNumber _randomNumber;
    public Sample()
    {
        _randomNumber = new RandomNumber();
    }
    public Sample(RandomNumber randomNumber)
    {
        _randomNumber = randomNumber;
    }
    public string GetRandomMessage()
    {
        ...
        int messageId = _randomNumber.GetRandomNumber(itemCount);
        ...
    }
}

Passing an object into the constructor means we now have Dependency Injection as we can pass the RandomNumber object in; and Dependency Inversion as our calling code controls which type of object is used.

A surprisingly simple concept and implementation that tends to be over complicated. There are a few other ways of achieving the dependency injection through setters and interfaces  but these are just variation on the same concept.

If you now think about this for a moment and consider the common layers you have in your application this could be Data Access Layer (DAL), Business layer, UI and possibly others like payment services and authentication, this dependency inversion at each layer would mean that ultimately all of your dependent objects need to be defined at the highest level the UI which is not really a good idea. To address this we have the Inversion of Control pattern.

Inversion of Control

When Inversion of Control is discussed today it can be used in place of Dependency Injection or more likely as a reference to the frameworks that help to manage the dependencies of loosely coupled systems. These may also be called Inversion of Control Containers.

We are not going to look at Inversion of Control as part of this series, however it is useful to be aware of the terminology.

In the next part of our series we are going to look at implementing the changes in our project, starting with the abstracting of a common interface.

Step 1. Refactoring

Further Reading

The concepts above are not new and there is a lot of further information available, these are some of the articles we found useful in putting together this simple overview.

Coupling (computer science) – WikiPedia

Dependency Inversion – WikiPedia

Dependency Injection – WikiPedia

Dependency Injection Demystified – James Shore (Must read!)

Inversion of Control and Dependency Injection: Working with Windsor Container – MSDN

Inversion of Control Containers and the Dependency Injection Patter – Martin Fowler (reading this last)

This entry was posted in Agile, Development, SharePoint and tagged , , . Bookmark the permalink.