我是否应该打扰单元测试我的存储库层

Question

只是把这个出来进行辩论.

我得到了单元测试.有时感觉很费时间,但我都是为了好处.

我使用IoC进行了包含存储库层和服务层的应用程序设置,并且我已经对这些方法进行了单元测试.

现在我知道隔离我的单元测试方法的好处,因此几乎没有依赖于其他方法.

我得到的问题是这个.如果我只通过我的服务层方法访问我的存储库方法,那么只测试服务层不够好吗？我正在测试测试数据库.

难道它不被认为是你只需要测试你的公共方法的想法的延伸吗？也许我只是想跳过一些测试;)

Answer 1

是的,您应该测试您的存储库层.虽然这些测试中的大多数都属于不同的测试分类.我通常将它们称为集成测试,以区别于我的单元测试.不同之处在于对资源(您的数据库)存在外部依赖性,并且这些测试可能需要更长的时间才能运行.

分别测试您的存储库的主要原因是您将测试不同的东西.存储库负责处理与您正在使用的任何持久性存储的转换和交互.另一方面,服务层负责将各种存储库和其他依赖项协调为表示业务逻辑的功能,这可能不仅仅涉及到存储库方法的中继,并且在某些情况下可能涉及对多个存储库的多次调用.

首先,澄清服务层测试 - 在测试服务层时,应该模拟存储库,以便它们与您在服务层中测试的内容隔离.正如您在评论中指出的那样,这为您提供了更精细的测试级别并隔离了测试中的代码.您的单元测试现在也会运行得更快,因为没有数据库连接可以减慢它们的速度.

现在,将集成测试添加到您的存储库有以下几个优点......

它允许您在编写代码时测试这些代码片段,即TDD.
它确保您正在使用的任何持久性语言(SQL,HQL,序列化对象等)都适合您正在尝试执行的操作.
如果您使用的是对象关系映射器,则可确保正确定义映射.
将来,您可能会发现需要支持其他类型的持久性.根据存储库测试的结构,您可以重用大量测试来验证新数据库架构是否正常工作.对于实现数据库特定逻辑的存储库方法,显然您必须创建单独的测试.
与Continuous Integration结合使用时,将存储库测试分开是件好事.集成测试本质上比单元测试需要更长的时间.因此,它们通常以较不频繁的间隔运行,因此运行单元测试可获得的即时反馈不会延迟.

这些都是我在我参与的各种项目中看到的所有优点.可能会有更多.

所有这一切,我会承认,我对存储库集成测试并不像单元测试那么彻底.例如,在测试特定对象的更新时,我通常会对成功更新一个数据库列进行内容测试,而不是为每个单独的列创建单独的测试,或者在一个测试中验证每个列的更大的测试.对我来说,这取决于存储库方法执行的操作的复杂性以及是否存在需要隔离的特殊条件.

Answer 2

您应该测试您的存储库层。但是，如果您有涵盖它的集成、故事或系统测试，那么您也可以很好地避免进行单元测试。

\n\n

单元测试对于复杂的独立对象来说非常有用，但是花很长时间为 \xe2\x80\x9chigher level\xe2\x80\x9d 测试涵盖的简单方法编写单元测试是没有意义的。

\n

Answer 3

这难道不取决于存储库访问层的智能程度吗？如果您的存储库采用参数来过滤（例如 Linq to SQL）给定的结果集，则肯定需要测试此逻辑。