CODEWITHSUNDEEP
c#unit-testingmockingrepositorymoq
vanpersil
vanpersil

Reputation: 814

Unit testing classes with mocked repository dependecies

I have a service class with several methods. Service has some dependencies on repositories. I am using Moq to mock the repository. I have a problem with the proper unit testing one of the methods. I will give you an example:

public interface IRepository<T>
{
    IEnumerable<T> FindAll();
    IEnumerable<T> FindByQuery(Predicate<T> predicate);
    //many other methods for retreiving T's
}

public class MyService
{
    private readonly IRepository<Category> _repo;

    public MyService(IRepository<Category> repo)
    {
        _repo = repo;
    }

    public List<Category> FindActiveCategories()
    {
        return _repo.FindAll().Where(x => x.Active).ToList();
    }
}

Now, I wrote a unit test:

public FindActiveCategories_WhenCalled_ShouldReturnActiveCategories() {
   var moq = new Mock<IRepository<Category>>();
   var list = new List<Category>
   {
       new Category {Active = true},
       new Category {Active = false}
   };
   moq.Setup(x => x.FindAll()).Returns(list);
   var service = new MyService(moq.Object);
   var result = service.FindActiveCategories();

   Assert.IsTrue(result.All(x=>x.Active));
}

And the test of course passed. But than I realized that I retreived all the Categories in my service method using FindAll - it was an obvious thing to correct, because I didn't want to load several thousands of categories to memory just to pull out only few of them. So I changed the implementation of FindActiveCategories method to this:

public List<Category> FindActiveCategories()
{
    return _repo.FindByQuery(x => x.Active).ToList();
}

And my test failed this time. The problems is obvious - the test depended on the implementation details. I knew that the FindActiveCategories method uses FindAll method of the repository, so I wrote a setup for this method. After changing the implementation I have to change the implementation of the test method - this seems to be a problem. Of course I could've setup all the Find... methods but there are plenty of them in the repository and one can choose many of them, this also doesn't seem right approach for me. Not to mention TDD - if I was trying to write the test first, I wouldn't know what and how to mock the repository interface. My question is: what is a correct way to handle this kind of dependencies to be able to write implementation independent unit tests.

Upvotes: 0

Views: 1025

Answers (2)

Richardissimo
Richardissimo

Reputation: 5763

Despite the title of this question, the actual question here seems to be "should I need to change my test if my code implementation changes?"

The answer to that is that if the implementation is entirely contained within your code under test then 'no'. For example, if I have a method to multiply two values and I implement it the obvious way, I can write tests to prove that it works. Now if I change the implementation to do the calculation using a for loop and accumulating a total within the loop, all of my tests should pass with no changes.

The problem is that most of the code we write isn't like that: it depends on other things. If the code under test depends on other things we have two choices: do an integration test, or mock the dependency.

  • The integration test supplies the class under test with the real dependencies that it would be using when actually in use. This is the most valuable testing, since it is completely realistic. The answer here would also be 'no need to change the test if you change the implementation'. However, this is often impractical, since it exponentially increases the cost of writing and maintaining the tests.
  • Mocking requires you to specify how the dependency should behave, so by definition, your test must know what the code under test is going to use, and how. Therefore if you change the implementation, you should reasonably expect to have to change the test, so the answer would be 'yes'.

However, consider this point. The parts of your test which do not relate to mocking should not need to change. You aren't using the Arrange Act Assert pattern (which can help make tests more readable, particularly when mocking); but the Act and Assert parts, which would be the last two lines of your test, should not need to change. Maybe that will allow you to believe you're still doing TDD.

But don't lose sleep over it: there are other things which would benefit from your attention more. For example, change the implementation of your method to...

public List<Category> FindActiveCategories()
{
    return new List<Category>();
}

... then the test will pass, even though the code won't do what you want (because the All in the assert returns true for an empty list).

Hope this was useful.

Upvotes: 1

Nkosi
Nkosi

Reputation: 247123

The following will work for the change made above.

[TestClass]
public class MyServiceShould {
    [TestMethod]
    public void FindActiveCategories_WhenCalled_ShouldReturnActiveCategories() {
        //Arrange
        var moq = new Mock<IRepository<Category>>();
        var list = new List<Category> {
            new Category {Active = true},
            new Category {Active = false}
        };
        moq
            .Setup(x => x.FindByQuery(It.IsAny<Predicate<Category>>()))
            .Returns((Predicate<Category> predicate) => list.Where(x => predicate(x)));
        var service = new MyService(moq.Object);

        //Act
        var result = service.FindActiveCategories();

        //Assert
        Assert.IsTrue(result.All(x => x.Active));
    }
}

The mock takes the passed predicate and applies it to the fake collection in order to allow the test to be exercised to completion.

Reference Moq Quickstart to get a better understanding of how to use the mocking framework.

Upvotes: 0

Related Questions