The state-of-the-practice in software development is driven by constant change fueled by continuous integration servers. Such constant change demands for frequent and fully automated tests capable to detect faults immediately upon project build. As the fault detection capability of the test suite becomes so important, modern software development teams continuously monitor the quality of the test suite as well. However, it appears that the state-of-the-practice is reluctant to adopt strong coverage metrics (namely mutation coverage), instead relying on weaker kinds of coverage (namely branch coverage). In this paper, we investigate three reasons that prohibit the adoption of mutation coverage in a continuous integration setting: (1) the difficulty of its integration into the build system, (2) the perception that branch coverage is "good enough", and (3) the performance overhead during the build. Our investigation is based on a case study involving four open source systems and one industrial system. We demonstrate that mutation coverage reveals additional weaknesses in the test suite compared to branch coverage and that it is able to do so with an acceptable performance overhead during project build.
翻译:软件开发方面的最新做法是由连续整合服务器推动的不断变化驱动的。这种不断的变化要求经常和完全自动化的测试要求,能够在项目建设时立即发现故障。随着测试套件的故障检测能力变得如此重要,现代软件开发团队也不断监测测试套件的质量。然而,看来最新做法不愿意采用强大的覆盖度(即突变覆盖),而依赖较弱的覆盖度(即分支覆盖 ) 。在本文中,我们调查了在连续整合环境中禁止采用突变覆盖的三个原因:(1) 难以将其纳入构建系统,(2) 认为分支覆盖“足够好 ”,(3) 建设过程中的业绩管理。我们的调查是以涉及四个开放源系统和一个工业系统的案例研究为基础。我们证明,与分支覆盖相比,测试套件的覆盖率变化暴露出更多的弱点,而且能够在项目建设期间以可接受的绩效管理方式做到这一点。