考虑实现仓储模式（或类似模式）。我将尽可能简洁地提供示例/说明：
在这个特定的实现中，仓储由一个名为IRepository的接口定义，该接口有一个方法将实体添加到仓储中，因此使得仓储依赖于泛型类型T（同时，仓储必须隐式地依赖于另一种类型TDataAccessLayer，因为抽象是仓储模式的全部意义。然而，这种依赖关系目前并不容易获得）。从我目前的理解来看，我有两个选择：单元测试和集成测试。
在集成测试中，可能会涉及更多的移动部分，但我更愿意最初进行单元测试，以至少验证基线功能。但是，如果没有创建某种“实体”属性（泛型类型T），我看不出任何断言Repository实现的Add()方法是否实际执行任何逻辑的方式。
也许，是否有一种介于单元测试和集成测试之间的中间地带，可以通过反射或其他方式验证已经在测试单元内部达到了特定的执行点？
对于这个特定问题，我想到的唯一解释是进一步将数据访问层从仓储中抽象出来，导致Add()方法不仅接受实体参数，还接受数据访问参数。但是，这似乎会破坏仓库模式的目的，因为仓库的使用者现在必须知道数据访问层。
关于示例请求：
（1）就单元测试而言，我不确定像仓储这样的东西是否可以使用我对当前测试技术的理解进行单元测试。因为仓储是特定数据访问层周围的抽象（包装器），所以似乎唯一的验证方法是集成测试？ （当然，仓储接口可能不与任何特定的DAL相关联，但是任何实现的仓储肯定与特定的DAL实现相关联，因此需要能够测试Add()方法是否实际执行某些工作）。
（2）就集成测试而言，据我了解，测试将通过实际调用Add()方法（应该将记录添加到仓库中）并检查数据是否实际添加到仓库（或在特定场景下的数据库中）来验证Add()方法是否执行工作。这可能看起来像：
所以，在这种情况下，假设存储库是数据库逻辑层的包装器，测试期间实际上会两次访问数据库（一次在插入期间，一次在检索期间）。
现在，我能看到有用的技术是验证某个执行路径在运行时是否被采取。例如，如果传递了非空引用，则验证采取执行路径A，如果传递了空引用，则验证采取执行路径B。此外，也许可以验证要执行特定的LINQ查询。因此，在测试期间实际上从未访问数据库（允许原型设计和开发实现而不需要任何实际的数据访问层）。
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的接口定义，该接口有一个方法将实体添加到仓储中，因此使得仓储依赖于泛型类型T（同时，仓储必须隐式地依赖于另一种类型TDataAccessLayer，因为抽象是仓储模式的全部意义。然而，这种依赖关系目前并不容易获得）。从我目前的理解来看，我有两个选择：单元测试和集成测试。
在集成测试中，可能会涉及更多的移动部分，但我更愿意最初进行单元测试，以至少验证基线功能。但是，如果没有创建某种“实体”属性（泛型类型T），我看不出任何断言Repository实现的Add()方法是否实际执行任何逻辑的方式。
也许，是否有一种介于单元测试和集成测试之间的中间地带，可以通过反射或其他方式验证已经在测试单元内部达到了特定的执行点？
对于这个特定问题，我想到的唯一解释是进一步将数据访问层从仓储中抽象出来，导致Add()方法不仅接受实体参数，还接受数据访问参数。但是，这似乎会破坏仓库模式的目的，因为仓库的使用者现在必须知道数据访问层。
关于示例请求：
（1）就单元测试而言，我不确定像仓储这样的东西是否可以使用我对当前测试技术的理解进行单元测试。因为仓储是特定数据访问层周围的抽象（包装器），所以似乎唯一的验证方法是集成测试？ （当然，仓储接口可能不与任何特定的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));
}
所以，在这种情况下，假设存储库是数据库逻辑层的包装器，测试期间实际上会两次访问数据库（一次在插入期间，一次在检索期间）。
现在，我能看到有用的技术是验证某个执行路径在运行时是否被采取。例如，如果传递了非空引用，则验证采取执行路径A，如果传递了空引用，则验证采取执行路径B。此外，也许可以验证要执行特定的LINQ查询。因此，在测试期间实际上从未访问数据库（允许原型设计和开发实现而不需要任何实际的数据访问层）。