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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…