集成测试最佳实践

Question

我工作的一个项目，面临

我创建的类中的方法找到了一些用户和应用逻辑下面的问题，这将引发一些意想不到返回其他用户对象要么异常id null或有一些值

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

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

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

感谢

Answer 1

这是我会为供应商特定的情况下做的 - 因为在甲骨文rownum和limit在MySQL两限行数回来后，我会在我的身边创造一个抽象，说，myLimit。根据供应商数据库的选择，它会映射到rownum或limit。

一旦你有了上述和任何其他必要的抽象涵盖了你的应用程序的所有方面，你可以开始设计集成测试。我建议的首选项是：（i）所有供应商的实际数据库连接，（ii）嵌入式数据库和（iii）模拟数据库。数据库本身并不需要很大。

基于质量保证指标，如果您认为数据库连接已经通过其他测试完全测试，那么我会在集成测试中使用嵌入式或模拟数据库。

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

Answer 2

关于单元和集成测试。

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

单元测试应当覆盖单元，其意味着我们覆盖相当小块代码。因此，单元测试通常涵盖非常特定的情况，通常有很多单元测试，因为对于一个小的方法，程序可能有几个方向，所有这些都应该被覆盖。所有令人不安的事情单元测试，比如说，有些方法是调用外部方而没有真正涉及到方法的业务逻辑必须嘲笑。

在集成测试，而不是因为你要测试整个管基本上，这意味着你的测试应该通过不同的模块（类），不要嘲笑任何它是不可取的嘲笑什么。这种类型的测试通常是相当大的，因此，我会建议而不是来处理集成测试中的一些小的验证检查，因为从我的角度来看，这不值得这样做。

如果我从我的角度正确理解你的情况，你的方法应该检查null而不是调用者。这是基于你不知道谁会打电话给你的方法。 您的方法应该预计允许输入参数中的所有不同值。