假设我们将数据访问层设计为具有nhibernate支持的存储库模式。
我想知道的是什么;在测试存储库时我们真正在测试什么？
我们是否正在测试Orm的工作是否正确，或者数据库是否可以按预期运行查询？
如果我有一个类似的存储库; OrderRepository，我为什么要测试Save，Update，FindbyId方法？
我认为唯一需要测试的是Orm映射其他对我没有意义的事情。
因为像Nhibernate这样的Orms，Entity Framework是成熟的框架所以;为什么我要担心＆＃34; context.Add（）＆＃34;或＆＃34; session.Save（）＆＃34;如果映射正确，是否正常工作？
答案 0 :(得分：0)
确实可能没有（或很少）回报该投资。有时测试就是这样。
这取决于您如何定义测试值。对于一些人来说，追逐难以捉摸的100％覆盖率具有内在价值。如果有时间构建这些测试，那很好。 100％的覆盖率是一个很好的温暖模糊。但是，正如你所暗示的那样，并非所有带来一个测试的测试都是真正有意义的。在这种情况下，通常的主要价值是100％覆盖率指标的炫耀权。 （例如，也许挑剔的客户希望在某个地方的某个报告上看到这个数字。）
或者，集成测试可能是ORM环境之外的有价值工具，也可能是用于构建DAL的其他工具。如果您从技术但非开发人员资源的角度将DAL视为黑盒子，他们可能需要一个可以测试 DAL接口的任何实现的工具并确保端到端，如果配置正确，该实现在实时环境中工作。
也许整个集成测试本身并没有测试代码，但从他们的角度来看，测试数据库和应用程序是否相互正确配置并相互通信。 那个人并不关心ORM或映射，他们关心UML图上的几个独立系统组件在系统规范的范围内协同工作。该组件是使用ORM，使用手动SQL还是使用神奇的小精灵粉尘对该测试没有任何影响。
这真的取决于团队中哪个角色想要测试以及他们实际尝试测试/验证的内容。