单元测试 – NerdDinner中的依赖注入 – 实际测试您的存储库或模
|
考虑一个处理依赖注入的初学者.我们正在分析NerdDinner中的两个相关类.
来自应用程序的DinnerRepository： 来自测试的FakeDinnerRepository： 它们实现了不同的逻辑,这当然是必要的,因为这里的关键思想是实现IDinnerRepository,并提供不同的实现和私有成员. 我理解测试是针对控制器的,但我担心数据访问逻辑有两种不同的实现.考虑使用任何类型的ORM,ADO.NET,SubSonic或您喜欢的任何数据访问类型的任何项目.是的,您可以设置您的假存储库以匹配真实的存储库. 我担心的是,随着时间的推移,真正的回购中的实施细节会发生变化.也许打字错误,或查询中的一些其他重要的实现细节更改.这导致模型中的假设与真实仓库之间的逻辑可能不匹配.担心的是真正的repo和test repo的实现变得不同步. 问题： >在这种情况下,您如何测试模型？
这可能不是你问题的完整答案,但我会尝试在那里找到一部分.
接口 – 在本例中为IDinnerRepository – 应该被视为合同.这意味着任何实施都必须履行此合同.如果方法是FindAllDinners(),那么基本上它应该做什么.用于单元测试的虚假存储库通常比真实存储库更简单(例如使用字典),因此实际上不应将实际实现视为一个问题,而应将其视为一项要求. 假存储库首先存在的原因是测试.基本上,应该测试所有可以测试的东西.将数据库排除在等式之外是内存虚假存储库的重点.数据访问不是测试的重点,因此我们将其替换.虚拟存储库的设置和使用速度要快得多,我们可以轻松确保存储库处于需要通过测试代码的状态. 所以你要做的是在你的单元测试中传递你的假存储库的副本,并确保模型代码中发生的任何事情都反映在假存储库中. 我想你会发现,在实践中,保持存储库同步不会是一个问题.如果需求发生变化,您将更改界面,并且两个实现都需要更改.如果意图发生变化,您可能会达到单位测试开始中断的程度. 希望这可以帮助！ （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |