unit-testing - 对存储库进行单元测试是否有意义？实体框架 4.1

Question

我一直在观看各种视频并阅读各种关于对存储库进行单元测试的博客。

最常见的模式是创建一个 Fake 存储库，该存储库实现与真实存储库相同的接口。然后假的使用内部字典或其他东西。

所以实际上你是在对永远不会投入生产的 fakerepository 的逻辑进行单元测试。

现在您可以使用依赖注入通过使用一些 IDBContext 接口来注入模拟 DBContext。但是，您只是在测试实际上只是转发到 dbcontext （被模拟）的每个存储库方法。

因此，除非每个存储库方法在调用 dbcontext 之前都有很多逻辑，否则它似乎有点毫无意义？

我认为将存储库上的测试作为集成测试并实际让它们访问数据库会更好吗？

新的 EF 4.1 使这变得简单，因为它可以根据测试项目中的连接字符串动态创建数据库，然后您可以在运行测试后使用 dbcontext.Database 方法将其删除。

score 4 · Accepted Answer

你的反对是部分正确的。它们的正确性取决于存储库的定义方式。

第一个伪造或模拟存储库不是用于测试存储库本身，而是用于使用存储库测试层。
如果存储库暴露IQueryable并且上层可以构建 linq-to-entities 查询，那么模拟存储库意味着测试不存在的逻辑。您需要集成测试并针对真实的测试数据库运行查询。您可以为每个测试重新部署数据库，这将使其非常慢，或者您可以在事务中运行每个测试并在测试完成时回滚它。
如果存储库没有公开IQueryable，您仍然可以将其视为黑盒并模拟它。查询逻辑将在存储库中，并将与集成测试分开测试。

我会向您推荐有关存储库本身和测试的其他答案集。

score 0 · Accepted Answer

我见过的最好的方法来自 Sharp Architecture，他们使用 SQLLite 数据库，基于 NHibernate 映射信息在 TestFixtureSetup 中创建。

存储库测试然后使用此内存中数据库。

从技术上讲，这仍然是涉及数据库的集成测试，但实际上，它勾选了单元测试的所有框，因为：

1）数据库是瞬态的 - 无需担心连接字符串配置，也不需要在某处的服务器上安装完整的数据库以供单元测试使用。

2）设置速度快，测试和内存一样。

3) 由于它使用 NHibernate 映射信息来生成模式，因此您不必担心单元测试设置与代码更改保持同步。

可以对 EF 使用相同的方法。

2 回答 2