是否有任何指标用于确定功能测试是否“满意”?
我觉得有一个客观的测量来创建一个比较测试类型的基线是有帮助的,常见的是代码覆盖率。
通过识别代码覆盖率,很容易比较功能测试和单元测试,功能测试是否覆盖与单元测试相同的代码行?如果是这样,那就多余了。
问题在于忽略了许多其他问题:
- 功能测试是否过长了?它们难以设置,还是仅在CI中执行?然后在单元测试中复制代码行是有意义的,这将为开发人员提供快速反馈。
- 这是POC还是不成熟的项目?功能测试可以提供最好的降压,因为它们应该能够断言更高级别的用例并从实现细节中抽象出来。当实施细节不确定时,这非常有用
- 代码覆盖率具有误导性,以IO为中心的库(即数据库驱动程序)可以通过模拟其依赖关系轻松实现100%的代码覆盖率。如果我们在这种情况下使用代码覆盖来比较功能测试和单元测试,我们将缺少测试的多个维度,因为功能测试将运用IO依赖性。 (在这种情况下,IMO单元测试实际上是一个非常小的值,并且在IO重代码中给出了错误的信心,导致通常在开发的后续周期中发现的集成错误,其中解决问题的成本更高
- 您触及边缘情况,功能测试通常会说明几个客户端流程。使用功能测试来处理所有边缘情况和错误处理通常会浪费资源并最终创建难以维护,速度慢的测试的大套件