使用存储库模式时测试域

Question

单元测试 (TDD) 让我大吃一惊。我有一个要测试的基本存储库模式，但我不确定我是否正确地做事。在这个阶段，我正在测试我的域，而不是担心控制器和视图。为了简单起见，这里有一个演示项目。

类

public class Person
{
    public int PersonID { get; set; }
    public string Name{ get; set; }
}

界面

public interface IPersonRepository
{
    int Add(Person person);
}

混凝土

public class PersonnRepository : IPersonRepository
{

    DBContext ctx = new DBContext();

    public int Add(Person person)
    {
        // New entity
        ctx.People.Add(person);
        ctx.SaveChanges();
        return person.id;

    }
}

我已将 NUnit 和 MOQ 添加到我的测试项目中，并想知道如何正确测试功能。

我不确定这是否正确，但在阅读了一些博客后，我最终创建了一个 FakeRepository，但是如果我基于此进行测试，那如何验证我的实际界面？

public class FakePersonRepository
{

    Dictionary<int, Person> People = new Dictionary<int, Person>();

    public int Add(Person person)
    {
        int id = People.Count + 1;
        People.Add(id, person);
        return id;
    }
}

然后用

测试

    [Test]
    public void Creating_A_Person_Should_Return_The_ID ()
    {

        FakePersonRepository repository = new FakePersonRepository();

        int id = repository.Add(new Person { Name = "Some Name" });

        Assert.IsNotNull(id);

    }

我是否可以在正确的庄园进行测试？

我想在以后测试诸如不传递名称会导致错误等问题。

Answer 1

我是否可以在正确的庄园进行测试？

恐怕你不是。拥有接口的想法是，它允许您解耦使用存储库（例如您的控制器）的其他代码，并能够对其进行单独的单元测试。因此，假设您有以下要进行单元测试的控制器：

public class PersonController : Controller
{
    private readonly IPersonRepository _repo;
    public PersonController(IPersonRepository repo)
    {
        _repo = repo;
    }

    [HttpPost]
    public ActionResult Create(Person p)
    {
        if (!ModelState.IsValid)
        {
            return View(p);
        }

        var id = _repo.Add(p);
        return Json(new { id = id });
    }
}

请注意控制器如何不依赖于特定的存储库实现。所有需要的是这个存储库实现给定的合同。现在我们可以在单元测试中使用 Moq 之类的模拟框架来提供一个假存储库，并使其按照我们喜欢的方式运行，以便测试 Create 操作中的 2 条可能路径：

[TestMethod]
public void PersonsController_Create_Action_Should_Return_View_And_Not_Call_Repository_If_ModelState_Is_Invalid()
{
    // arrange
    var fakeRepo = new Mock<IPersonRepository>();
    var sut = new PersonController(fakeRepo.Object);
    var p = new Person();
    sut.ModelState.AddModelError("Name", "The name cannot be empty");
    fakeRepo.Setup(x => x.Add(p)).Throws(new Exception("Shouldn't be called."));

    // act
    var actual = sut.Create(p);

    // assert
    Assert.IsInstanceOfType(actual, typeof(ViewResult));
}


[TestMethod]
public void PersonsController_Create_Action_Call_Repository()
{
    // arrange
    var fakeRepo = new Mock<IPersonRepository>();
    var sut = new PersonController(fakeRepo.Object);
    var p = new Person();
    fakeRepo.Setup(x => x.Add(p)).Returns(5).Verifiable();

    // act
    var actual = sut.Create(p);

    // assert
    Assert.IsInstanceOfType(actual, typeof(JsonResult));
    var jsonResult = (JsonResult)actual;
    var data = new RouteValueDictionary(jsonResult.Data);
    Assert.AreEqual(5, data["id"]);
    fakeRepo.Verify();
}

Answer 2

您需要通过为其提取接口来使您的 DBContext 可注入：

public interface IDBContext{
   IList<Person> People {get;}  // I'm guessing at the types
   void SaveChanges();
   //      etc.
}

然后将其注入到您的具体类中：

public class PersonRepository : IPersonRepository
{

    IDBContext ctx;

    public PersonRepository(IDBContext db) {
       ctx = db;
    }

    public int Add(Person person)
    {
        // New entity
        ctx.People.Add(person);
        ctx.SaveChanges();
        return person.id;

    }
}

您的测试将如下所示：

[Test]
public void Creating_A_Person_Should_Return_The_ID ()
{

    Mock<IDBContext> mockDbContext = new Mock<IDBContext>();
    // Setup whatever mock values/callbacks you need

    PersonRepository repository = new PersonRepository(mockDbContext.Object);

    int id = repository.Add(new Person { Name = "Some Name" });

    Assert.IsNotNull(id);

    // verify that expected calls are made against your mock
    mockDbContext.Verify( db => db.SaveChanges(), Times.Once());
   //...

}

Answer 3

我个人会考虑为此编写一个“集成测试”，即一个访问真实（ish）数据库的测试，因为您的数据访问层不应包含任何使隔离测试值得的逻辑。

在这种情况下，您需要启动并运行数据库。这可能是已经在某处设置的开发人员数据库，或者作为测试安排的一部分启动的内存数据库。

这样做的原因是，我发现 DAL 的（纯）单元测试通常最终证明您可以使用模拟框架等等，但最终不会让您对自己的代码充满信心。

如果您对单元测试完全陌生，并且手头没有大学来帮助您设置 DAL 测试所需的环境，那么我建议您暂时停止测试 DAL，并专注于业务逻辑，因为是您将获得最大收益的地方，并且可以让您更轻松地了解测试将如何帮助您。