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

【问题标题】：Is there a point Unit Testing a Repository? Entity Framework 4.1对存储库进行单元测试是否有意义？实体框架 4.1
【发布时间】：2011-07-01 12:30:54
【问题描述】：

我一直在观看各种视频并阅读各种博客，他们在其中对存储库进行单元测试。

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

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

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

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

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

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

【问题讨论】：

【解决方案1】：

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

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

我会向您推荐有关repository itself and testing 的其他答案。

【讨论】：

【解决方案2】：

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

然后存储库测试使用这个 In-Memory 数据库。

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

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

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

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

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

【讨论】：

听起来很有趣，但它再次测试了一些不会投入生产的东西。我更喜欢在本地或构建服务器上为测试动态创建一个数据库，这很容易使用 EF 4.1
很多单元测试，测试不会投入生产的东西。任何时候你有一个 FixtureSetup 过程，你都会引入一些模拟实时系统行为的东西。但是，总的来说，我同意 - 我还没有发现这种性质的测试值得进行设置。