来自应用程序的DinnerRepository：
来自测试的FakeDinnerRepository：
它们实现了不同的逻辑,这当然是必要的,因为这里的关键思想是实现IDinnerRepository,并提供不同的实现和私有成员.
我理解测试是针对控制器的,但我担心数据访问逻辑有两种不同的实现.考虑使用任何类型的ORM,ADO.NET,SubSonic或您喜欢的任何数据访问类型的任何项目.是的,您可以设置您的假存储库以匹配真实的存储库.
我担心的是,随着时间的推移,真正的回购中的实施细节会发生变化.也许打字错误,或查询中的一些其他重要的实现细节更改.这导致模型中的假设与真实仓库之间的逻辑可能不匹配.担心的是真正的repo和test repo的实现变得不同步.
问题：
>在这种情况下,您如何测试模型？
>测试模型是否合适？
>确保您的测试跟上业务逻辑的实施是否是一个纪律问题？
接口 – 在本例中为IDinnerRepository – 应该被视为合同.这意味着任何实施都必须履行此合同.如果方法是FindAllDinners(),那么基本上它应该做什么.用于单元测试的虚假存储库通常比真实存储库更简单(例如使用字典),因此实际上不应将实际实现视为一个问题,而应将其视为一项要求.
假存储库首先存在的原因是测试.基本上,应该测试所有可以测试的东西.将数据库排除在等式之外是内存虚假存储库的重点.数据访问不是测试的重点,因此我们将其替换.虚拟存储库的设置和使用速度要快得多,我们可以轻松确保存储库处于需要通过测试代码的状态.
所以你要做的是在你的单元测试中传递你的假存储库的副本,并确保模型代码中发生的任何事情都反映在假存储库中.
我想你会发现,在实践中,保持存储库同步不会是一个问题.如果需求发生变化,您将更改界面,并且两个实现都需要更改.如果意图发生变化,您可能会达到单位测试开始中断的程度.
希望这可以帮助！
