Towards refactoring-aware regression test selection

Towards refactoring-aware regression test selection
复制标题

走向重构意识回归测试选择

DOI:
10.1145/3180155.3180254
复制
发表时间:
2018
期刊:
International Conference on Software Engineering
影响因子:
--
通讯作者:
Gligoric, Milos
Gligoric, Milos
中科院分区:
--
文献类型:
--
作者:
Wang, Kaiyuan;Zhu, Chenguang;Celik, Ahmet;Kim, Jongwook;Batory, Don;Gligoric, Milos

文献摘要

相似文献

回归测试检查最近的项目更改不会中断以前工作的功能。尽管很重要,但当更改频繁时,回归测试的成本会很高。回归测试选择(RTS)通过只运行其结果可能受更改影响的测试来优化回归测试。传统上,RTS收集每个测试的依赖项(例如,对文件的依赖项),并跳过依赖项没有更改的新项目修订版中的测试。现有的RTS技术没有将保持行为的转换(即重构)与其他代码更改区分开来。因此,测试运行的频率比必要的更高。我们介绍了面向重构的RTS技术的第一步,称为REKS,该技术跳过仅受保留行为的更改影响的测试。Reks定义在不运行测试的情况下更新测试依赖项的规则。为了确保Reks不会隐藏重构引擎引入的任何错误,我们在预提交测试阶段集成Reks Only,这发生在开发人员的机器上。我们通过衡量测试工作中的节省来评估Reks。具体地说,我们在GitHub上再现了37个项目的开发人员执行的100个重构任务。我们的结果显示,Reks平均不会运行33%的可用测试(这将由不知道重构的RTS技术运行)。此外,我们在10个项目上系统地运行了27种重构类型。基于74,160个重构任务的结果显示,Reks平均不会运行16%的测试(最大值:97%,SD:24%)。最后,我们的结果表明Reksupdate规则是有效的。
Regression testing checks that recent project changes do not break previously working functionality. Although important, regression testing is costly when changes are frequent. Regression test selection (RTS) optimizes regression testing by running only tests whose results might be affected by a change. Traditionally, RTS collects dependencies (e.g., on files) for each test and skips the tests, at a new project revision, whose dependencies did not change. Existing RTS techniques do not differentiate behavior-preserving transformations (i.e., refactorings) from other code changes. As a result, tests are run more frequently than necessary.We present the first step towards a refactoring-aware RTS technique, dubbed Reks, which skips tests affected only by behavior-preserving changes. Reksdefines rules to update the test dependencies without running the tests. To ensure that Reksdoes not hide any bug introduced by the refactoring engines, we integrate Reksonly in the pre-submit testing phase, which happens on the developers' machines. We evaluate Reksby measuring the savings in the testing effort. Specifically, we reproduce 100 refactoring tasks performed by developers of 37 projects on GitHub. Our results show that Rekswould not run, on average, 33% of available tests (that would be run by a refactoring-unaware RTS technique). Additionally, we systematically run 27 refactoring types on ten projects. The results, based on 74,160 refactoring tasks, show that Rekswould not run, on average, 16% of tests (max: 97% and SD: 24%). Finally, our results show that the Reksupdate rules are efficient.