【问题标题】：Does Unit Tests still matter if Functional Tests is satisfied?如果满足功能测试，单元测试是否仍然重要？
【发布时间】：2017-02-26 14:24:00
【问题描述】：
简要总结：
- 单元测试是较小的测试，希望在开发人员看来能够正确执行。
- 功能测试是那些期望事情在用户看来是正确的
如果功能测试已经满足，我们还需要做单元测试吗？
最有可能（让我们使用 Web 开发作为上下文），这很常见，通过使用浏览器让其他用户/人尝试系统/应用程序来查看事情是否正确。
让我们推出其他测试，例如边缘情况。
【问题讨论】：
标签：
unit-testing
testing
functional-testing
software-quality
【解决方案1】：
您是否使用任何指标来确定功能测试是否“满意”？
我觉得有一个客观的测量来创建一个基线来比较测试类型是有帮助的，一个常见的就是代码覆盖率。
通过识别代码覆盖率很容易比较功能测试和单元测试，功能测试是否覆盖与单元测试相同的代码行？如果是这样，那就是多余的。
问题是这忽略了很多其他问题：
- 功能测试运行时间是否过长？它们难以设置，还是仅在 CI 中执行？那么在单元测试中复制代码行可能是有意义的，这将为开发人员提供快速反馈。
- 这是一个 POC 还是一个不成熟的项目？功能测试可能是物有所值的，因为它们应该能够断言更高级别的用例并从实现细节中抽象出来。当实施细节不确定时，这非常有用
- 代码覆盖率具有误导性，一个以 IO 为中心的库（即 DB 驱动程序）可以通过模拟其依赖关系轻松实现 100% 的代码覆盖率。如果我们在这种情况下使用代码覆盖率来比较功能测试和单元测试，我们将丢失多个测试维度，因为功能测试将执行 IO 依赖项。 （在这种情况下，IMO 单元测试实际上是一个很小的值，并且会给 IO 繁重的代码带来错误的信心，从而导致通常在开发的后期周期中发现的集成错误，而修复问题的成本更高
- 您谈到了边缘情况，功能测试通常会说明几个客户端流程。使用功能测试执行所有边缘案例和错误处理通常会浪费资源，最终会创建大量难以维护、速度缓慢的测试套件