存储库本身通常不经过测试？

Question

抱歉，我对存储库模式、单元测试和 orm 工具还不熟悉。

我一直在研究单元测试和存储库模式，并得出一些结论，我想知道我是否正确。

存储库模式有助于在使用它的控制器中替换单元测试，例如，对吧？因为创建上下文（在 EF 中）或会话（在 NH 中）的存根/伪造比较困难，对吧？存储库本身没有经过测试？为什么？

使用 EntityFramework 或 NHibernate 与存储库模式，如果我想测试我的存储库，我需要进行集成测试吗？因为如果我使用上下文/会话的假实现，我就不会进行真正的测试？因为上下文/会话本身就是存储库（我的意思是它们实现了添加、删除、编辑、GetById、GetAll 等真正的逻辑）？

带有 EF 或 NH 的存储库模式就像一个包装器？ （不仅仅是一个包装器，我知道这是域的一个重要概念。）

Answer 1

Repository接口属于领域层。但实现属于基础设施或数据访问层。此实现通常不通过单元测试进行测试。它大量使用 ORM API，因此单独测试存储库非常困难且浪费。此问题并非特定于存储库： Don'不要模拟您不拥有的类型。

存储库应该使用真正的 ORM 通过集成测试进行测试。 内存数据库是一个非常解决这个问题的流行方法。

...因为如果我使用假的
我的上下文/会话的实现我没有进行真正的测试？

即使你设法做到了（我真的怀疑 NHibernate 的情况），你也会浪费时间。会话/上下文接口不受您的控制，您的测试只会重申您对真实事物如何工作的猜测。

因为上下文/会话本身就是存储库？

不。 Context/Session 是 UnitOfWork 模式的实现。它不是您的域的一部分。这是基础设施。

带有 EF 或 NH 的存储库模式就像一个包装器？

存储库是重要的领域概念，它不仅仅是一个“包装器”。就像您的应用程序不是数据库的“包装器”一样。我认为 DDD 存储库接口定义应该尽可能基于通用语言，并且不应该包含任何ORM 相关的单词或类型。

Answer 2

在这种情况下，我会严格区分 EF 和 NH，并且我不会在同一问题中包含这两种技术。 Simple NH 更加成熟，并且具有导致代码更容易测试的架构。另外，在 NH 的情况下，您可以简单地将数据库切换到另一个数据库（例如 SQLite），它仍然可以正常工作，而在 EF 的情况下则不一定如此，因为切换数据库可能会导致测试完全不同的应用程序 - 特别是如果您可以在 MS 和非 MS 数据库之间切换。

什么是存储库？让我们看看 Martin Fowler 的定义：

存储库在域和数据映射层之间进行中介，
就像内存中的域对象集合一样。客户端对象
以声明方式构建查询规范并将其提交给
满意的存储库。可以添加和删除对象
存储库，因为它们可以来自简单的对象集合，以及
存储库封装的映射代码将执行
适当的幕后操作。从概念上讲，存储库
封装了保存在数据存储中的一组对象
对它们执行的操作，提供更加面向对象的视图
的持久层。存储库还支持以下目标
实现域之间的完全分离和单向依赖
和数据映射层。

很好的定义。现在考虑一下DbSet的用途：

• 它充当内存收集吗？是的，您可以使用它从数据库获取实体或使用 Local 属性获取已加载的实体。
• 客户端可以声明式查询规格吗？是的，它称为 linq-to-entities。
• 可以从集合中添加或删除对象吗？是的，可以。
• 映射是否被封装？是的。
• 是否有干净的分离？从逻辑上来说是的。就 API 而言，否，因为将 IDbSet 暴露给域模型将使域模型依赖于技术 - EF。是不是有问题？理论上是的，对于纯粹主义者来说是的，但在 99% 的情况下这确实不是问题，因为需要更改 API 的情况很少见，而且即使您正确地分离了 API，它也总是涉及很大的更改。

DbSet 是一个存储库。直接使用 DbSet 和将其包装到某个通用存储库中的唯一区别是分离。这导致我以前对类似问题的回答 - EF 4.1 的通用存储库有什么意义

现在，存储库在您的应用程序中的用途是什么？我看到您之前的问题，包括这个 您的 BaseRepository 构建在实体框架之上。如果您认真地将其视为一个基础存储库，它将成为您的专用存储库的父级，该存储库致力于域模型的聚合根并公开仅与特定公开实体类型相关的专用方法，那么是的 - 您正在使用存储库模式并且您需要它。但是，如果您只是包装上下文和单个集合并调用此存储库，您很可能只创建了具有可疑附加值的冗余层，因为那只是 DbSet 之上的包装器。

在这种情况下，只有一种情况您的存储库（DbSet 包装器）才有意义：

• 包装器永远不会公开 IQueryable （linq-to-entities）
• 包装器永远不会公开接受Expression<>并将其内部传递给IQueryalbe（linq-to-entities）

这是唯一一个为您提供完全可模拟存储库的场景=>您的上层可以轻松进行单元测试。您不会对存储库进行单元测试，也不会模拟存储库中使用的上下文。存储库包装数据访问和映射逻辑 - 对于存储库，唯一合理的测试是集成测试。这个场景有什么问题？您将失去 LINQ 的全部功能，并且必须包装/重新实现 EF 中实现的一些方法和类型。这种类型的存储库与使用存储过程包装数据访问时使用的存储库相同。

如果你不遵循这种情况，你的生活就会容易得多。您将拥有由 LINQ 定义的查询，但您将无法对代码进行单元测试，因为没有模拟/伪造仍会将查询评估为 linq-to-entities。一旦您模拟了 DbSet 或 IQueryable，您将使用 linq-to-object，它是 linq-to-entities 的超集。您可以轻松编写一个查询，该查询将通过模拟 DbSet 的测试，但在运行时使用真实的 DbSet 会失败。 这里是有关此问题的更多信息这里是将通过的查询示例测试但在运行时失败。在这种情况下，您必须对在存储库顶部使用 linq-to-entities 查询的所有方法使用集成测试（使用真实数据库）。

Answer 3

创建存储库只是数据库访问的轻量级包装器，并将业务方法放入依赖于存储库的实体服务层中，这是很常见的。因此，您可以使用包装存储库（例如内存数据库）来对实体服务进行单元测试。

Answer 4

当单元测试时，您需要明确您正在测试的“单元”。在测试您的单元时，您可以模拟单元之外的事物。您嘲笑的事物本身可能会被单独测试。

还有另一种测试，可以测试较大的部件。所以你可以测试你的代码+存储库+数据库。这很有价值，但它并没有测试相同的东西。特别是在使用真实数据库时，很难强制您的代码走上某些错误路径。

您应该测试{您的代码+存储库}并模拟数据库吗？取决于存储库本身的复杂程度和测试程度。