集成测试与测试覆盖率

Question

我的公司有一条规则，通过单元测试或集成测试达到75%的测试覆盖率。由于整个系统的复杂性，开发人员倾向于编写集成测试(例如，在运行的应用程序上使用selenium webdriver )，而不是承担模仿依赖服务/类的负担。

我不是这样的朋友，我想知道i-test的测试覆盖率数据实际上意味着什么：

在我看来，测试应该定义预期的行为并对其进行测试。如果i-test深入到应用程序中，通过许多服务，可能向下到DB层，然后再返回，它将覆盖很多行，但绝对不清楚这样的覆盖行的预期行为是什么。因此，覆盖率数据的质量是有问题的，而且--更糟糕的是--增加了维护工作。

该POV是否正确？当涉及到与管理层的讨论时，我如何支持它？

Answer 1

关于测试覆盖率的盲目百分比规则并不是很理想。集成测试就是一个很好的例子。如果有什么东西坏了，你能准确地说出是什么坏了吗？如果您有多个集成点(例如，单个请求命中数据库、web服务并发送电子邮件)，该怎么办？有太多的事情要做，测试没有真正的意义。

你能在不测试所有可能结果的情况下拥有100%的覆盖率吗？你能写一万个测试，但仍然不能覆盖一个软件中最重要的类吗？盲目的指标是糟糕的，并且在质量上没有真正的结果。

通常，更小、更离散的测试更有价值。我们通过清除集成点并在测试中模拟它们来做到这一点。然后，您可以设置这样的场景：“如果数据库执行此操作，那么我的代码将执行此操作。”在内存中解决这种类型的问题要比设置数据库在可重复的基础上做同样的事情容易得多。您将如何自动化服务器断开连接的集成测试？这是非常困难的。清除数据库处理特定SQL异常要容易得多，而且可重复得多。

Answer 2

如果你不能在截止日期前达到75%的测试覆盖率，或者即使你达到了，剩下的25%会发生什么，所以你的公司不会专注于获得一个不那么明显的缺陷的产品，而是专注于测试coverage.Explain的百分比，尽管你使用了selenium或其他所谓的东西，但你的方法是可信的。