Does refactoring break tests and to what extent?
- Kashiwa, Yutaro ORCID Kyushu University, Japan
- Shimizu, Kazuki Kyushu University, Japan
- Lin, Bin ORCID Istituto del software (SI), Facoltà di scienze informatiche, Università della Svizzera italiana, Svizzera
- Bavota, Gabriele ORCID Istituto del software (SI), Facoltà di scienze informatiche, Università della Svizzera italiana, Svizzera
- Lanza, Michele ORCID Istituto del software (SI), Facoltà di scienze informatiche, Università della Svizzera italiana, Svizzera
- Kamei, Yasutaka Kyushu University, Japan
- Ubayashi, Naoyasu ORCID Kyushu University, Japan
- 2021
Published in:
- 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME), Luxembourg, 2021. - 2021, p. 171-182
English
Refactoring as a process is aimed at improving the quality of a software system while preserving its external behavior. In practice, refactoring comes in the form of many specific
and diverse refactoring operations, which have different scopes and thus a different potential impact on both the production and the test code. We present a large-scale quantitative study complemented by a qualitative analysis involving 615,196 test
cases to understand how and to what extent different refactoring operations impact a system’s test suites. Our findings show that while the vast majority of refactoring operations do not or very seldom induce test breaks, some specific refactoring types (e.g., “RENAME ATTRIBUTE” and “RENAME CLASS”) have a higher chance of breaking test suites. Meanwhile, “ADD PARAMETER” and “CHANGE RETURN TYPE” refactoring operations often require additional lines of changes to fix the test suite they break. While some modern IDEs provide features to automatically apply these two types of refactoring operations, they are not always able to avoid test breaks, thus demanding extra human efforts.
and diverse refactoring operations, which have different scopes and thus a different potential impact on both the production and the test code. We present a large-scale quantitative study complemented by a qualitative analysis involving 615,196 test
cases to understand how and to what extent different refactoring operations impact a system’s test suites. Our findings show that while the vast majority of refactoring operations do not or very seldom induce test breaks, some specific refactoring types (e.g., “RENAME ATTRIBUTE” and “RENAME CLASS”) have a higher chance of breaking test suites. Meanwhile, “ADD PARAMETER” and “CHANGE RETURN TYPE” refactoring operations often require additional lines of changes to fix the test suite they break. While some modern IDEs provide features to automatically apply these two types of refactoring operations, they are not always able to avoid test breaks, thus demanding extra human efforts.
- Collections
- Language
-
- English
- Classification
- Computer science and technology
- License
- License undefined
- Open access status
- green
- Identifiers
-
- DOI 10.1109/ICSME52107.2021.00022
- ARK ark:/12658/srd1325321
- Persistent URL
- https://n2t.net/ark:/12658/srd1325321
Statistics
Document views: 27
File downloads:
- Lin_2021_IEEE_Proceedings.pdf: 64