ASP.NET MVC - 如何在存储库模式中对边界进行单元测试？

Question

给定一个基本的存储库接口：

public interface IPersonRepository
{
    void AddPerson(Person person);
    List<Person> GetAllPeople();
}

通过一个基本的实现：

public class PersonRepository: IPersonRepository
{
    public void AddPerson(Person person) 
    {
        ObjectContext.AddObject(person);
    }

    public List<Person> GetAllPeople()
    {
        return ObjectSet.AsQueryable().ToList();
    }
}

如何以有意义的方式对其进行单元测试？由于它跨越边界并物理更新并从数据库读取，因此这不是单元测试，而是集成测试。

或者一开始就想对其进行单元测试是错误的吗？我应该只对存储库进行集成测试吗？

我一直在谷歌上搜索这个主题，博客经常说制作一个实现 IRepository 的存根：

public class PersonRepositoryTestStub: IPersonRepository
{
    private List<Person> people = new List<Person>();
    public void AddPerson(Person person) 
    {
        people.Add(person);
    }

    public List<Person> GetAllPeople()
    {
        return people;
    }
}

但这并不对 PersonRepository 进行单元测试，它测试 PersonRepositoryTestStub 的实现（不是很有帮助）。

Answer 1

在这种特定情况下，我认为您不需要为存储库类进行单元测试，因为实现只是调用 ObjectContext 对象，所以这就像测试您没有构建的东西（这不是这个想法）。如果您没有任何复杂的逻辑，我的建议是不要浪费时间为该类进行单元测试。您所说的 PersonRepositoryTestStub 是存储库的一个假实现，用于测试 DAL 之上的层。

Answer 2

我遇到了同样的问题。我针对我的存储库接口的实现编写了大量单元测试，该存储库接口是一个假存储库。完成后不久，我意识到我编写单元测试是为了测试假存储库，而我编写假存储库只是为了支持单元测试。这看起来像是大量无用的代码。

我得出的结论是，我不需要单元测试，但假存储库实现很好，因为我可以将它用作我的服务（以及我的控制器）使用的存储库，以便针对这些的单元测试是可预测的（感谢预定义的假存储库）。

因此，我决定将针对假存储库的单元测试保留在那里，因为它们有助于测试我的假存储库，以便我可以放心，我的应用程序的更高级别正在使用经过充分测试的假存储库。

换句话说，假存储库和针对假存储库的单元测试是更高级别应用程序的“支持演员”以及针对更高级别应用程序的单元测试。

希望有帮助。

Answer 3

我认为这种类型的测试有意义的时候是当你的存储库接口是通用的时。例如，

public interface IEntity
{
    int Id { get; set; }
}

public interface IRepository<TEntity>
    where TEntity : IEntity
{
    void Add(TEntity entity);
    List<TEntity> GetAll();
}

如果您有该接口的多个实现，那么还可以编写一个针对该接口进行测试的通用测试装置，从而允许您使用单个测试装置测试多个存储库实现。这种方法不区分单元测试和集成测试，因为它不知道实现是什么。

如果您对此类事情感兴趣，请告诉我，我可以发布一个完整的示例。

Answer 4

我将测试直接依赖于 DAL 实现（对 DAL 精确实现具有强引用）或间接依赖于 DAL 实现（通过接口从 DAL 抽象）的业务逻辑层。

我不太喜欢使用存根实现的测试，只需将数据库调用包装到未提交的事务中（当测试完成时，即使抛出异常，也会回滚所有数据更改）。