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

Question

真的把它拿出去辩论。

我接受了单元测试。有时候感觉很费时间，但我都是为了好处。

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

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

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

这不能被视为您只需要测试公共方法的想法的延伸吗？也许我只是想跳过一些测试;）

Answer 1

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

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

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

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

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

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

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

Answer 2

您应该测试您的存储库层。但是，如果你有覆盖它的集成，故事或系统测试，那么你也可以做一个没有单元测试的好例子。

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

  

我接受单元测试

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