集成测试最佳实践

Question

我正在开展一个项目并面临以下问题

我在类中创建了一个方法来查找某个用户并应用逻辑，如果返回了意外的内容，则抛出异常，否则用户对象的id为null或者有一些值

我为所有测试用例编写了单元测试，现在在被调用者中我忘了添加null id的条件。

处理这类错误的最佳做法是什么。我应该在所有测试用例中编写集成测试吗？或者集成测试应该只有快乐的路径吗？

其次，在集成测试中，使用嵌入式数据库而不是实际的数据库是否合适？我当时正在考虑使用嵌入式数据库进行集成测试，但是如何测试特定于供应商的查询，例如oracle中的rownum和mysql中的限制。在我的实际环境中，我们使用的是oracle和嵌入式数据库，我可以使用h2。我使用普通的jdbc

由于

Answer 1

这就是我要为供应商特定情况做的事情 - 因为Oracle中的rownum和MySQL中的limit都限制了返回的行数，我会在我这边创建一个抽象，比如{ {1}}。根据供应商数据库的选择，它会映射到myLimit或rownum。

如果您拥有上述内容以及涵盖应用程序各个方面的任何其他必要抽象，您就可以开始设计集成测试。我建议的首选项是：（i）实际数据库连接，（ii）嵌入式数据库，以及（iii）模拟数据库，适用于所有供应商。数据库本身不需要太大。

根据QA指标，如果您认为其他测试对数据库连接进行了彻底测试，那么我将在集成测试中使用嵌入式或模拟数据库。

正如您所看到的，答案取决于系统的其他部分的测试情况！祝你好运。

Answer 2

关于单元和集成测试。

让我们澄清一下这些类型的测试之间的区别。

单元测试应该是覆盖单元，这意味着我们正在覆盖相当小块代码。因此，单元测试通常涵盖非常具体的情况，通常有很多单元测试，因为对于一个小方法，程序可能有几个方向，所有这些都应该被覆盖。所有令人不安的单元测试的东西，例如，一些调用外部方并且与方法的业务逻辑无关的方法必须被模拟。

在集成测试中，不建议模拟任何东西，因为你想要测试整个管道基本上这意味着你的测试应该通过不同的模块（类）并且不要嘲笑任何东西。这种类型的测试通常非常庞大，因此，我建议 不 在集成测试中处理一些小的验证检查，因为从我的角度来看认为不值得这样做。

如果从我的角度理解你的情况，你的方法应该检查null而不是调用者。它基于这样一个事实：你永远不知道谁会打电话给你的方法。 您的方法应该期望输入参数中允许的所有不同值。