NerdDinner中的依赖注入 - 实际测试您的存储库或模型

Question

考虑一个处理依赖注入的初学者.我们正在分析NerdDinner中的两个相关类.

来自应用程序的DinnerRepository:

来自测试的FakeDinnerRepository:

它们实现了不同的逻辑,这当然是必要的,因为这里的关键思想是实现IDinnerRepository,并提供不同的实现和私有成员.

我理解测试是针对控制器的,但我担心数据访问逻辑有两种不同的实现.考虑使用任何类型的ORM,ADO.NET,SubSonic或任何您喜欢的数据访问类型的项目.是的,您可以设置您的假存储库以匹配真实的存储库.

我担心的是,随着时间的推移,真正的回购中的实施细节会发生变化.也许打字错误,或查询中的一些其他重要的实现细节更改.这导致模型中的假设与真实仓库之间的逻辑可能不匹配.担心的是真正的repo和test repo的实现变得不同步.

问题:

• 在这种情况下,您如何测试模型？
• 是否适合测试模型？
• 确保您的测试跟上业务逻辑的实现是否是纪律问题？

Answer 1

这可能不是您问题的完整答案，但我会尽力提供部分答案。

该接口（在本例中为 IDinnerRepository）应被视为契约。这意味着任何实施都必须履行此合同。如果该方法是 FindAllDinners()，那么这基本上就是它应该做的事情。用于单元测试的假存储库通常比真实的存储库（例如使用字典）简单得多，因此跟上真实的实现确实不应该被视为问题，而应将其视为一项要求。

假存储库存在的首要原因是测试。基本上，所有可以测试的东西都应该测试。将数据库排除在外是内存中假存储库的重点。数据访问不是测试的重点，所以我们替换它。假存储库的设置和使用速度要快得多，我们可以轻松确保存储库处于测试代码通过所需的状态。

因此，您要做的就是在单元测试中向模型传递假存储库的副本，并确保模型代码中发生的任何情况都反映在假存储库中。

我想你会发现在实践中，保持存储库同步不会有问题。如果需求发生变化，您将更改接口，并且两个实现都需要更改。如果意图改变，您的单元测试可能会开始崩溃。

希望这可以帮助！