The right way to use MOQ setup and returns

Question

Im new to MOQ and I am a little confused with the setup method. The example below shows one method that i need to test. The method under test returns the latest time from two dates, so I create two datetime objects and pass them to my function. The part where I'm confused is the returns call. This ignores the logic in my method and returns what I tell it to. For example if i say returns(date2) then the assert passes regardless of the logic. Am I doing something wrong?

public virtual DateTime LatestTime(DateTime t1, DateTime t2)
{
   if (t1.CompareTo(t2) > 0)
      return t1;

    return t2;
}

[Test]
[Category("Catalogue service")]
public void TestLatestTimeReturnsCorrectResult()
{
    //Arrange
    DateTime date1 = new DateTime(2014, 07, 25, 13, 30, 01);
    DateTime date2 = new DateTime(2014, 07, 25, 13, 30, 00);

    MockCatalogueService.Setup(x => x.LatestTime(date1, date2)).Returns(date2);

    //Act
    DateTime retDate = MockCatalogueService.Object.LatestTime(date1, date2);

    //Assert
    Assert.That(retDate == date2);
}

Solution

You use Moq in the wrong way. It is intended to substitute some implementations your tested class is dependent on. For example, you are testing some class that uses a DB repository:

public class MyService
{
    private IMyDbRepository _repos;
    
    public MyService(IMyDbRepository dbRepos)
    {
        _repos = dbRepos;
    }

    public string[] GetClientNames()
    {
        return _repos.GetAllClients().Where(c=>!c.IsDisabled).OrderBy(c=>c.Name).ToArray();
    }
}

You need to test the GetClientNames() method. But you can't until you have IMyDbRepository instance. It's too complicated and wrong to create and fill database just to test method of sorting and filtering clients.

The way out is to use Moq:

[Test]
public void TestGetAllClientsDoesNotReturnDisabledUsers()
{
    var dbReposMock = new Mock<IMyDbRepository>();
    dbReposMock.Setup(r=>r.GetAllClients()).Returns(
                      new []{ new Client { Name="AAA", IsDisabled=true },
                              new Client { Name="BBB", IsDisabled=false } });

    var myTestingService = new MyService(dbReposMock.Object);//You pass here the autogenerated object which follows the described primitive behavior without requiring DB at all.
    var clientNames = myTestingService.GetClientNames();
    Assert.AreEqual(1, clientNames.Length);
    Assert.AreEqual("BBB", clientNames[0]);
}

So Moq allows you to generate fake class (non-sealed) or interface implementations on the fly (in runtime) and use them to decouple your testing functionality from everything else. Consequently, if a bug appears in the DB structure, you see only a few DB-tests failing and can easily identify what is the problem comparing to the case when 100 different tests from all layers failing if you didn't decouple the code with Moq.