简短总结:
- 单元测试是较小的测试，它期望某些东西在开发人员看来是正确的。
- 功能测试是那些期望事情在用户看来是正确的
如果功能测试已经满足，我们还需要做单元测试吗？
最有可能(让我们使用网络开发作为上下文)，这很常见，通过使用浏览器让其他用户/人尝试系统/应用程序来查看事情是否正确。
让我们推出其他测试，例如边缘情况。
最佳答案
您是否使用任何指标来确定功能测试是否“令人满意”？
我觉得有一个客观的衡量标准有助于创建基线来比较测试类型，常见的一个是代码覆盖率。
通过识别代码覆盖率，可以轻松比较功能测试和单元测试，功能测试是否覆盖与单元测试相同的代码行？如果是这样，那就多余了。
问题是这忽略了大量其他问题:
- 功能测试的运行时间是否过长？它们很难设置，还是只能在 CI 中执行？那么在单元测试中重复代码行可能是有意义的，这将为开发人员提供快速反馈。
- 这是 POC 还是不成熟的项目？功能测试可能会提供最好的效果，因为它们应该能够断言更高级别的用例并从实现细节中抽象出来。当实现细节不确定时，这非常有用
- 代码覆盖率具有误导性，以 IO 为中心的库(即 DB 驱动程序)可以通过模拟其依赖项轻松实现 100% 的代码覆盖率。在这种情况下，如果我们使用代码覆盖率来比较功能测试和单元测试，我们将缺少多个维度的测试，因为功能测试将执行 IO 依赖性。 (在这种情况下，IMO 单元测试实际上是一个非常小的值，并且对 IO 繁重的代码给出了错误的信心，导致集成错误通常在开发的后期周期中被发现，修复问题的成本更高
- 您谈到了边缘情况，功能测试通常会说明几个客户端流程。使用功能测试来执行所有边缘情况和错误处理通常会浪费资源，并最终创建大量难以维护的缓慢测试
关于unit-testing - 如果满足功能测试，单元测试还重要吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42469686/