中间地带存在吗?(单元测试与集成测试)

考虑Repository模式（或类似模式）的实现。我会尽量保持例子/插图的简洁性：

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.
    }
}

在该特定实现中存储库由接口IRepository定义为具有将实体添加到存储库的一个方法，从而使Repository依赖于泛型类型T（此外，Repository必须隐式地依赖于另一种类型TDataAccessLayer，因为抽象是Repository模式的全部点。然而，这种依赖目前还不可用）。在这一点上，根据我目前的理解，我有两个选择：单元测试和集成测试。

在集成测试可能被假设有更多的移动部件的情况下，我更愿意最初进行单元测试，以便至少验证基线功能。然而，如果不创建某种"实体"属性（泛型类型T），我看不出有任何方法可以断言任何逻辑实际上是在Repository实现的Add（）方法中执行的。

单元测试和集成测试之间是否存在中间地带，允许（通过反射或其他方式）验证在测试单元内是否达到了特定的执行点？

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

关于请求示例：

（1） 关于单元测试，根据我对当前测试技术的理解，我不确定像Repository这样的东西是否真的可以进行单元测试。因为存储库是围绕特定数据访问层的抽象（包装器），所以似乎唯一的验证方法是集成测试？（诚然，存储库接口可能不与任何特定的DAL绑定，但任何已实现的存储库都必须与特定的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));
}

因此，在本例中，假设存储库是某个数据库逻辑层的包装器，那么在测试期间数据库实际上会被命中两次（一次在插入期间，一次在检索期间）。

现在，我认为有用的是一种在运行时验证是否采用了特定执行路径的技术。例如，如果传入非null引用，则采用验证执行路径a，如果传入null引用，那么采用验证执行道路B。此外，也许可以验证要执行特定的LINQ查询。因此，数据库在测试过程中从未真正命中（允许在没有任何实际DAL的情况下对实现进行原型设计和开发）。