单元测试存储库有没有意义？实体框架4.1

Question

我一直在观看各种视频和阅读各种博客，他们去了单元测试存储库。

最常见的模式是创建一个与真实界面相同的界面的伪造仓库。然后假的使用内部字典或其他东西。

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

现在，您可以使用依赖注入通过使用某些IDBContext接口来注入模拟DBContext。然而，你只是测试每个存储库方法，实际上只是转发到dbcontext（这是嘲笑）。

因此，除非在调用dbcontext之前每个存储库方法都有很多逻辑，那么它看起来有点无意义？

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

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

Answer 1

您的异议部分正确。它们的正确性取决于存储库的定义方式。

• 首先伪造或模拟存储库不是用于测试存储库本身，而是用于使用存储库测试图层。
• 如果资源库公开IQueryable并且上层可以构建linq-to-entities查询，那么模仿资源库意味着测试不存在的逻辑。您需要集成测试并针对真正的测试数据库运行查询。您可以为每个测试重新部署数据库，这会使测试非常缓慢，或者您可以在事务中运行每个测试，并在测试完成时将其回滚。
• 如果存储库不公开IQueryable你仍然可以把它想象成一个黑盒子并嘲笑它。查询逻辑将存储在存储库中，并将通过集成测试单独进行测试。

我会引用你关于repository itself and testing的其他答案的集合。

Answer 2

我见过的最好的方法是从夏普架构，他们使用SQLLite数据库，在基于NHibernate映射信息的TestFixtureSetup中创建。

存储库测试然后使用这个内存数据库。

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

1）数据库是暂时的 - 没有连接字符串CONFIGS担心，也不是你需要一个完整的数据库坐在某个服务器上供单元测试使用。

2）设置速度快，测试同样如此，所有内存。 3）因为它使用NHibernate映射信息来生成模式，所以你不必担心保持单元测试设置与代码更改同步。

http://wiki.sharparchitecture.net/default.aspx?AspxAutoDetectCookieSupport=1

它可能会使用与EF相同的方法。