Unit Testing and dependencies

Question

I'm just learning how to do proper unit testing, and a lot of resources make reference to using explicit dependencies, ie dependencies that are passed into the constructor, to allow for easy mocking/stubbing, etc.

This obviously makes sense.

What isn't clear to me is where should these objects be created, and how do you unit test those methods?

As an example, say you have an ASP.net ActionMethod. This makes use of a class that requires 3 dependencies, would you simply 'new' those up in the ActionMethod? If so, how then would you test that ActionMethod?

Answer 1

Most likely those objects are created from a factory or from a single point where the object graph is created as indicated from @guillaume31 comments. If from factory it would look something like this:

namespace Repository.Lookup
{
    public class LookupRepositoryFactory
    {
        public static ILookupRepository Create()
        {
            ILookupRepository lookupRepository = new LookupRepository(); 

            return lookupRepository;
        }
    }
}

Then the test for the factory:

namespace RepositoryTests.Lookup
{
    [TestClass]
    public class LookupRepositoryFactoryTests
    {
        [TestMethod]
        public void TestCreateLookupRepository()
        {
            var expectedType = typeof(LookupRepository);

            var repository = LookupRepositoryFactory.Create();

            Assert.IsInstanceOfType(repository, expectedType);
        }
    }
}

Then usage:

var lookupRepository = LookupRepositoryFactory.Create();

Then you just pass in that on the constructor as you have mentioned, like so:

namespace CommonLookupAPI
{
    public class GenericLookup
    {
        private readonly ILookupRepository _repository;

        public GenericLookup(ILookupRepository repository)
        {
            _repository = repository;
        }

        public List<CommonLookup> GetCommonLookup(LineOfBusiness lineOfBusiness, ClassificationType classificationType,
            State state, Grouping grouping, SubGrouping subGrouping)
        {
            var commonLookups = _repository.GetCommonLookup(lineOfBusiness, classificationType, state, grouping, subGrouping);
            return commonLookups;
        }
    }
}

This allows one to mock the repository with a fake implementation so you can test generic lookup without using the real repository.

Here are the tests:

namespace CommonLookupAPITests
{
    [TestClass]
    public class GenericLookupTests
    {
        [TestMethod]
        public void TestGenericLookupReturnsLookup()
        {
            ILookupRepository repository = MockRepositories.CreateMockSuccessRepository();
            var genericLookup = new GenericLookup(repository);

            var lookups = genericLookup.GetCommonLookup(LineOfBusiness.AssistedLivingProfessionalLiability, ClassificationType.ClaimLimit, State.NotDefined, Grouping.NotDefined, SubGrouping.NotDefined);

            Assert.AreEqual(lookups.Count, 0);
        }

        [TestMethod]
        [ExpectedException(typeof(Exception))]
        public void TestGenericLookupReturnsFailUnExpected()
        {
            ILookupRepository repository = MockRepositories.CreateMockFailRepositoryException();
            var genericLookup = new GenericLookup(repository);

            var lookups = genericLookup.GetCommonLookup(LineOfBusiness.AssistedLivingProfessionalLiability, ClassificationType.ClaimLimit, State.NotDefined, Grouping.NotDefined, SubGrouping.NotDefined);
        }

        [TestMethod]
        [ExpectedException(typeof(DataAccessException))]
        public void TestGenericLookupReturnsFailDataAccess()
        {
            ILookupRepository repository = MockRepositories.CreateMockFailRepositoryDataAccessException();
            var genericLookup = new GenericLookup(repository);

            var lookups = genericLookup.GetCommonLookup(LineOfBusiness.AssistedLivingProfessionalLiability, ClassificationType.ClaimLimit, State.NotDefined, Grouping.NotDefined, SubGrouping.NotDefined);
        }
    }
}

And finally the Mock Repositories that the tests use:

namespace CommonLookupAPITests
{

    public class MockRepositories
    {
        public static ILookupRepository CreateMockSuccessRepository()
        {
            ILookupRepository repository = new MockSuccessRepository();
            return repository;
        }

        public static ILookupRepository CreateMockFailRepositoryException()
        {
            ILookupRepository repository = new MockFailRepositoryException();
            return repository;
        }

        public static ILookupRepository CreateMockFailRepositoryDataAccessException()
        {
            ILookupRepository repository = new MockFailRepositoryDataAccessException();
            return repository;
        }
    }

    public class MockSuccessRepository : ILookupRepository
    {
        public List<CommonLookup> GetCommonLookup(LineOfBusiness lineOfBusiness, ClassificationType classificationType,
            State state, Grouping grouping, SubGrouping subGrouping)
        {
            var commonLookup = new List<CommonLookup>();
            return commonLookup;
        }
    }

    public class MockFailRepositoryException : ILookupRepository
    {
        public List<CommonLookup> GetCommonLookup(LineOfBusiness lineOfBusiness, ClassificationType classificationType,
            State state, Grouping grouping, SubGrouping subGrouping)
        {
            throw new Exception();
        }
    }

    public class MockFailRepositoryDataAccessException : ILookupRepository
    {
        public List<CommonLookup> GetCommonLookup(LineOfBusiness lineOfBusiness, ClassificationType classificationType,
            State state, Grouping grouping, SubGrouping subGrouping)
        {
            throw new DataAccessException();
        }
    }
}

Answer 2

I don't know ASP.NET, but generally your dependencies would be on interfaces, and in your unit tests you provide mock, stub, or fake implementations of those interfaces. This lets you test your class in isolation, since the only code under test is the class itself plus your "skeleton" dependencies.

Answer 3

What isn't clear to me is where should these objects be created

Anywhere except in the dependent object itself, obviously. The point is that the consumer object doesn't control its dependency's lifecycle, someone else does.

One possible global approach to this is to compose the entire application's object graph in a single place, the Composition Root, located as close as possible to the application entry point. What it does concretely is new up all objects that are predictably instantiatable at that point and wire them up together using constructors.

As an example, say you have an ASP.net ActionMethod. This makes use of a class that requires 3 dependencies, would you simply 'new' those up in the ActionMethod?

Of course not -- the ActionMethod doesn't know how the class it uses is built, let alone controls how this dependency's dependencies are newed up :)

how then would you test that ActionMethod?

As you said, by passing mocks or stubs in the Controller's constructor or as arguments to the ActionMethod itself.