用于简短摘要：
- 单位测试是较小的测试，希望在开发人员的角度进行某件事。
- 功能测试是那些期望事情在用户视图中正确的测试
如果已经满足了功能测试，我们仍然需要进行单元测试吗？
最有可能（让我们将Web开发用作上下文），这是通过使用浏览器来查看事物是否合适的，让其他用户/人员尝试系统/应用程序是很常见的。
让我们进行其他测试，例如边缘案例。
您是否使用任何指标来确定功能测试是否"满足"？
我觉得有助于进行客观测量以创建比较测试类型的基线，常见的是代码覆盖范围。
通过识别代码覆盖范围，可以易于比较功能测试和单元测试，功能测试是否涵盖与单位测试相同的代码行？如果是多余的话。
问题是，这忽略了许多其他问题：
- 功能测试是否长期运行？它们难以设置，还是仅在CI中执行？然后，在单位测试中复制代码行可能有意义，这将为开发人员提供快速的反馈。
- 这是POC还是一个未成熟的项目？功能测试可能会为您提供最佳的收益，因为它们应该能够主张更高级别的用例并从实施细节中抽象出来。当实施细节不确定 时，这将非常有帮助
- 代码覆盖范围具有误导性，以IO为中心的图书馆（IE，DB驱动程序）可以通过嘲笑其依赖项来轻松获得100％的代码覆盖范围。如果我们使用代码覆盖范围来比较在这种情况下的功能测试和单元测试，则我们将缺少多个测试维度，因为功能测试将行使IO依赖性。（在这种情况下，IMO单元测试实际上是一个很小的价值，并且对IO重型代码产生了错误的信心，从而导致集成错误通常在DEV的后期周期中被发现，在此，解决问题的问题更昂贵
- 您触及了边缘案例，功能测试通常会说明几个客户端流。使用功能测试行使所有边缘案例和错误处理通常往往是浪费资源，最终会创造出难以维护的巨大套件，慢速测试