测试Entity Framework 5 - 内存数据库是一个好选择吗？

Question

我很感激这里已经有了许多关于实体框架测试的问题。然而，我遇到了Effort，它允许在内存中使用数据库上下文的版本。我猜我在这个领域有一些问题：

1. 使用这种方法的利弊是什么？

2. 我认为EF和内存数据库使用存储库和工作单元模式，这是否意味着在使用此方法时我们不需要自己实现？

3. 还有其他选项，比如提供虚假的IDBSet、使用SQL CE或实现存储库和工作单元模式，我是不是最好使用其中一种技术？

我感到有点不知所措。我意识到可能没有银弹，但希望得到一些指导。

谢谢

- davy

---

非常模糊的问题 - 但您可能会发现这个链接有用：http://www.codeproject.com/Articles/460175/Two-strategies-for-testing-Entity-Framework-Effort - ErikEJ

我还没有尝试过在EntityFramework中使用它，但是“切换到内存SQLite数据库”的方法对于NHibernate非常有效。这比完全模拟数据库查询所需编写的代码量更加优越。 - Patryk Ćwiek

@ErikEJ - 谢谢，是的，我看过那个例子并基于它做了一些工作。我想知道比我更有经验的人认为这是否是一个好方法。 - davy

Answer 1

1) 优点：您可以测试您的DAL函数是否实际工作，您不需要花费大量时间模拟存储库，只要实例化它，您就可以更快地运行测试（在大型项目上需要数小时）。缺点：您实际上没有测试您的实际数据库-这违背了集成测试的目的。另外，更改数据库是一个配置字符串。稍后编辑：我曾经做过很多单元测试，现在我更喜欢垂直切片。我发现当我关心数据库时，我已经到了需要进行集成测试的地步。

个人而言，我喜欢端到端测试，因为它使测试集中化-减少了数量，并实际针对规范进行测试。

2) UOW和仓储模式有助于不同的事情。仓储封装了DAL并应该抽象出db提供者本身 - 通常通过工作单元模式。工作单元本质上为您提供了事务访问，并应为您在测试时使用内存中的db提供钩子。因此，我个人认为它们并不是无用的。当您想要测试和模拟dal（例如进行小型单元测试而不是接受/集成）时，重复模式将为自己付费。您可以没有它吗？可能，但拥有它的成本微不足道，而且使一切变得整洁有序。此外，正如上面所暗示的那样，当我最终需要实现db时，我确实希望进行集成测试 - 我发现这些可以轻松从ui级别实现，因为我已经从外部工作/测试过。

3) 不知道，这不是任何人都能为您回答的问题。试着玩一下。

- John Nicholas