单元测试存储库是否有一点？实体框架4.1

Question

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

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

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

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

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

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

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

Answer 1

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

• 第一个假冒或模拟存储库不是用于测试存储库本身，而是用于使用存储库测试图层。
• 如果存储库公开IQueryable并且上层可以构建linq-to-entities查询，则模拟存储库意味着测试不存在的逻辑。您需要集成测试并针对实际测试数据库运行查询。您可以为每个测试重新部署数据库，这将使其非常慢，或者您可以在事务中运行每个测试并在测试完成时回滚它。
• 如果存储库未公开IQueryable，您仍然可以将其视为黑盒子并嘲笑它。查询逻辑将在存储库中，并将使用集成测试单独测试。

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

Answer 2

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

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

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

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

2）设置速度很快，测试结果与内存中的所有测试相同。

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

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

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