This paper presents a comprehensive catalogue of 57 test-specific refactoring types, out of which only 33 were previously documented in the literature, using a mixed-method approach grounded on three sources of data.
Abstract
Unlike traditional refactorings, research on test-specific refactoring is limited. This paper presents a comprehensive catalogue of 57 test-specific refactoring types, out of which only 33 were previously documented in the literature. We have identified and classified those refactorings using a mixed-method approach grounded on three sources of data: a) Existing datasets of test-modifying commits, b) Monitoring of latest contributions to popular GitHub repositories, and c) Stack Overflow discussions. Our findings reveal that tools have limited support for test-specific refactorings. And, unlike the existing literature that mainly associates refactoring activity in tests with test smell resolution, test refactoring is driven by various motivations, such as improving test understandability, accommodating changes in production code, and test framework migration. Finally, we provide actionable implications for researchers and tool builders.
Results indicate that static checks and test-guided, context-aware agentic repair can increase the reliability of LLM-generated refactorings, bringing them closer to practical integration within developer workflows.
Jonathan Cordeiro, Shayan Noei, Ying Zou· 1 citation
Results show that ML-enhanced recommendations outperform traditional methods in accuracy, relevance, and impact on maintainability metrics, and highlight the potential of integrating ML into modern development practices to support developers in producing cleaner, more maintainable software systems.
Rohit Malhotra· International Journal of Mod...· 0 citations
Refactoring is widely used to improve internal software quality; however, its impact on external functionality remains insufficiently explored. This study investigates how different refactoring operations influence software functionality through a controlled experimental analysis. A set of ten commonly used refactoring operations was applied to the jEdit system. Software functionality was quantitatively evaluated using a composite metric derived from cohesion, polymorphism, interface size, design size, and inheritance hierarchy. The selected ten refactoring operations were performed 453 times across ten independent experiments in jEdit. The results reveal that refactoring operations do not have uniform effects on functionality. Operations that enhance encapsulation and modular distribution significantly improve functionality, with Encapsulate Field achieving the highest increase. In contrast, operations that reduce abstraction, such as Inline Method and Inline Class, negatively impact functionality. Additionally, some operations show no measurable effect, indicating limitations in metric sensitivity. These findings demonstrate that refactoring should not be assumed to universally improve software functionality. Instead, its impact depends on the nature and context of the operations being applied. The study provides empirical evidence and practical guidance for selecting refactoring operations that effectively enhance functional quality while avoiding potential degradation.
Abdullah Almogahed, Manal Othman, M. Qasim et al.· 2026 6th International Confe...· 0 citations
Modern software development involves parallel work and concurrent changes, requiring code merging. Prior studies report that 10% to 20% of merge attempts result in conflicts, often requiring manual intervention. The literature explores factors that generate conflicts, including refactorings, but does not analyze how individual refactoring types influence the manual effort required to resolve them. We analyzed 64 open-source Java projects and applied association rule mining to measure the strength of associations between specific refactoring types and merge effort. Our results show that refactoring types relate to merge effort with varying strength. In particular, Rename Attribute, Move Class, Extract Variable, Change Return Type, and Split Parameter exhibit some of the strongest associations, especially when a higher number of such refactorings is present in the merge branches. We also find that both the number of refactorings and their diversity independently increase merge effort, both in terms of occurrence and intensity. Additionally, the co-occurrence of refactorings across parallel branches is associated with higher merge effort, particularly when combining structural transformations with changes to method signatures and data-structure representations, whereas more localized changes are less frequent in the most impactful combinations.
A. Oliveira, João Victor Monteiro, V. Neves et al.· 0 citations
This work introduces RepoProbe, a novel benchmark for evaluating repository-level code understanding through open-ended Q&A using GitHub Discussions, which focuses on open-ended architectural inquiries rather than defect reporting and proposes a Checklist-Based Verification Protocol that decomposes answers into atomic, verifiable facts, thereby replacing subjective ratings with objective verification.
Developers use automated Move refactorings to improve the modular structure of source code and the assignment of responsibilities. Class- and method-level Move refactorings are automated in modern IDEs, but statement- and expression-level moves that adjust method boundaries remain largely unautomated. We formalize five variants of Move Statement refactoring as preconditions and steps grounded in four basic conditions covering data reachability, execution count, side effects, and syntactic constraints required for compilation, of which all but the side-effect condition are checked statically. Combined with existing techniques, this also yields finer-grained moves of expressions and partial expressions. We further refine the formalization iteratively against a real project, deriving twenty additional preconditions and steps that handle Java syntactic diversity in practice. We evaluate applicability and compilability on ten projects, and behavior preservation in a case study on one of them: Move Statement refactorings yield compilable code in 93.3-97.0% of applicable cases, and the case study shows that the observed behavioral changes stem from side-effect reordering left to developer judgment, not from defects in the statically checked conditions.
Kota Yasuhara, Shinpei Hayashi· 0 citations
We use cookies to run the site and, with your consent, for analytics and to show ads.
See our Cookie Policy.
