c# - 中间立场存在吗？ (单元测试与集成测试)

Question

考虑存储库模式(或类似模式)的实现。我会尽量保持示例/插图简洁:

interface IRepository<T>
{
    void Add(T entity);
}

public class Repository<T> : IRepository<T>
{
    public void Add(T entity)
    {
        // Some logic to add the entity to the repository here.
    }
}

在这个特定的实现中，Repository 由接口(interface) IRepository 定义，有一个方法可以将实体添加到存储库，从而使 Repository 依赖于泛型类型 T(此外，Repository 必须隐式依赖于另一种类型 TDataAccessLayer ，因为抽象是存储库模式的全部要点。但是，这种依赖性目前并不容易获得)。在这一点上，据我目前的了解，我有两个选择:单元测试和集成测试。

如果假设集成测试有更多的移动部件，我宁愿首先进行单元测试，以便至少验证基线功能。但是，如果不创建某种“实体”属性(通用类型 T)，我看不出有任何方法可以断言任何逻辑实际上是在 Repository 实现的 Add() 方法中执行的。

也许在单元测试和集成测试之间有一个中间地带，允许(通过反射或其他方式)验证已在测试单元内达到特定的执行点？

我对这个特定问题提出的唯一解释是进一步从存储库中抽象数据访问层，导致 Add() 方法不仅接受实体参数，还接受数据访问参数。在我看来，这可能会破坏存储库模式的目的，但是，因为存储库的使用者现在必须了解数据访问层。

关于示例请求:

(1) 关于单元测试，根据我对当前测试技术的理解，我不确定像存储库这样的东西是否真的可以进行单元测试。因为存储库是围绕特定数据访问层的抽象(包装器)，所以似乎唯一的验证方法是集成测试？ (当然，存储库接口(interface)可能不绑定(bind)到任何特定的 DAL，但任何已实现的存储库肯定必须绑定(bind)到特定的 DAL 实现，因此需要能够测试 Add() 方法是否实际执行某些工作)。

(2) 关于集成测试，据我所知，该测试将通过实际调用 Add() 方法(应该向存储库添加记录)来验证 Add() 方法执行工作，并且然后检查数据是否实际添加到存储库(或者在特定情况下可能是数据库)。这可能看起来像:

[TestMethod]
public void Add()
{
    Repository<Int32> repository = new Repository<Int32>();
    Int32 testData = 10;

    repository.Add(testData);

    // Intended to illustrate the point succinctly. Perhaps the repository Get() method would not
    // be called (and a DBCommand unrelated to the repository issued instead). However, assuming the
    // Get() method to have been previously verified, this could work.
    Assert.IsTrue(testData == repository.Get(testData));
}

因此，在这种情况下，假设存储库是某个数据库逻辑层的包装器，数据库实际上在测试期间被命中两次(一次在插入期间，一次在检索期间)。

现在，我认为有用的是一种技术，用于验证在运行时是否采用了特定的执行路径。例如，如果传入非空引用，则验证执行路径 A，如果传入空引用，则验证执行路径 B。此外，也许可以验证是否要执行特定的 LINQ 查询。因此，数据库在测试期间从未真正受到影响(允许在没有任何实际 DAL 的情况下实现原型(prototype)设计和开发)。

Answer 1

听起来您是在描述实现细节的测试，而不是模式实现者对模式要求的满足。在测试单元内是否达到“特定执行点”并不重要，只有具体实现者维护接口(interface)契约才重要。出于测试目的创建 T 实体的测试是完全可以接受的，这就是模拟的目的。