The right way to use MOQ setup and returns

问题:

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);


    }

回答1:

You use Moq in a wrong way. It is intended to substitute some implementations your tested class is dependent on. For example, you are testing some class which 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 generating fake class (non-sealed) or interface implementations on the fly (in runtime) and use then to decouple your testing functionality from everything else. Consequently if bug appears in the DB structure, you see only 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.