Unit Testing without DI

Question

I am starting a small ASP.NET MVC project, each task on the board must come with unit tests. The project is small, just a few pages with not that much processing, so I decided not to implement DI. My thoughts being DI is for larger projects with dependency graphs.

However, now I am writing tests it has made me realise testing is more difficult. There is no constructor injection going on, so mocking these objects being used by the controller actions is proving troublesome.

If there are objects being instantiated on the action due to lack of contructor injection how can you mock them to test?

Answer 1

Here's a question: does this look like DI?

public class MyCar
{
    private IEngine _engine;

    public MyCar(IEngine engine)
    {
        _engine = engine;
    }

    public MyCar()
        : this(new MyV8Engine())
    {

    }
}

It should, because it IS DI. Dependency Injection is about injecting a dependency into an object, instead of placing the burden of new'ing up or finding the dependency on the object that requires it. DI is not about using a framework, it is a design pattern that solves an issue.

It is very valid for small applications to use constructor-based injection and new'ing up objects in default constructors. The reason you don't see this as an example of DI is because often times your dependency graph quickly becomes very big and unwieldy and the move to a DI framework rapidly becomes advantageous as your application grows.

Answer 2

If there are objects being instantiated on the action due to lack of contructor injection how can you mock them to test?

You can refactor your code to encapsulate all code that should be mocked away into a seperate protected methods and then use partial-mocks to replace that logic.

Example (in java)

Original

protected void moveFiles(File[] destFiles, File[] sourceFiles) {
    int pos = 0;
    while (pos < fileCount) {
        File sourceFile = sourceFiles[pos];
        File destFile = destFiles[pos];

        // do some processing. i.e. rename destFile if it already exists.

        // do the copy. the test should not execute this
        sourceFile.renameTo(destFile)
        pos++;
    }
}

refactored:

protected void moveFiles(File[] destFiles, File[] sourceFiles) {
    int pos = 0;
    while (pos < fileCount) {
        File sourceFile = sourceFiles[pos];
        File destFile = destFiles[pos];

        // do some processing. i.e. rename destFile if it already exists.
        osFileMove(destFile, sourceFile);
        pos++;
    }
}

/** can be replaced by mock/stub in unittests */
protected boolean osFileMove(File destFile, File sourceFile) {
    return sourceFile.renameTo(destFile);
}

in the test you can replace osFileMove with a fake (example uses java org.mockito.Mockito)

import static org.mockito.Mockito.*;

FileCommands sut;
@Before
public void setup() {
    sut = spy(new FileCommands());
    doReturn(true).when(sut).osCreateDirIfNeccessary(any(File.class));
    doReturn(true).when(sut).osFileCopy(any(File.class), any(File.class));
    doReturn(true).when(sut).osFileMove(any(File.class), any(File.class));
    doReturn(true).when(sut).osDeleteFile(any(File.class));
}

If you later decide to use ioc you can move the os-spcific file operations osxXXXX into a seperate class plus an interface