我应该打扰单元测试我的存储库层吗答案

【问题标题】：Should I bother unit testing my repository layer我应该打扰单元测试我的存储库层吗
【发布时间】：2010-12-15 17:24:58
【问题描述】：

真的只是把这个拿出来辩论。

我进行单元测试。有时觉得很费时间，但我完全是为了好处。

我使用 IoC 设置了一个包含存储库层和服务层的应用程序，并且我一直在对这些方法进行单元测试。

现在我知道将我的方法隔离以进行单元测试的好处，因此对其他方法的依赖很少或没有。

我的问题是这个。如果我只通过我的服务层方法访问我的存储库方法会仅测试服务层不够好？我正在针对测试数据库进行测试。

难道不可以将其视为您只需要测试公共方法的想法的延伸吗？也许我只是想跳过一些测试；）

【问题讨论】：

【解决方案1】：

是的，您应该测试您的存储库层。尽管这些测试中的大多数属于不同的测试分类。我通常将它们称为集成测试，以将它们与我的单元测试区分开来。不同之处在于资源（您的数据库）存在外部依赖性，并且这些测试可能需要更长的时间才能运行。

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

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

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

它允许您在编写这些代码时对其进行测试，类似于 TDD。
它确保您使用的任何持久性语言（SQL、HQL、序列化对象等）都针对您尝试执行的操作正确制定。
如果您使用的是对象关系映射器，它可以确保您的映射定义正确。
将来，您可能会发现需要支持另一种类型的持久性。根据存储库测试的结构，您可能能够重用大量测试来验证新的数据库模式是否正常工作。对于实现数据库特定逻辑的存储库方法，显然您必须创建单独的测试。
与持续集成结合使用时，最好将存储库测试分开。集成测试本质上比单元测试需要更长的时间来运行。因此，它们通常以较低频率运行，因此运行单元测试的即时反馈不会延迟。

这些都是我在我从事的各种项目中看到的所有优势。可能还有更多。

说了这么多，我承认我对存储库集成测试没有单元测试那么彻底。例如，在测试特定对象的更新时，我通常满足于测试一个数据库列是否已成功更新，而不是为每个单独的列创建单独的测试或验证一个测试中的每一列的更大的测试。对我来说，这取决于存储库方法正在执行的操作的复杂性以及是否有任何特殊情况需要隔离。

【讨论】：

【解决方案2】：

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

单元测试非常适合复杂的独立对象，但是对于“更高级别”测试所涵盖的简单方法花费很长时间编写单元测试是没有意义的。

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

单元测试：测试单个逻辑（一种方法），而不用担心该逻辑的依赖性。大多属于白盒类别。

集成测试：可以测试端到端的流或多个层一起测试，以确保其正确性。大多属于黑盒类别。

在 Dao 中大多数时候没有业务逻辑，它只是为特定的数据库实现形成查询。因此，如果我们已经在集成测试中涵盖了单元测试，则无需进行单元测试。不过，如果里面有一些逻辑，我们可以为 Dao 编写单元测试。

由于 dao 层与数据库实现紧密耦合，大多数时候 junit test for dao 已成为测试底层数据库的同义词。我们构建的查询只能由底层数据库引擎验证。

我曾经为dao编写单元测试（可以调用集成测试），通过使用实际数据库或模拟具有兼容数据库的数据库（遵循相同的sql标准，例如mysql引擎可以替换为sqlite或内存H2数据库) 并在 dao 中注入此数据库以测试 dao 层并在该 dao 层中查询构建。

【讨论】：

【解决方案5】：

我进行单元测试

下一步是测试驱动开发 (TDD)。它会回答你的问题。

【讨论】：