An Exploratory Study on the Relationship between Changes and Refactoring

IIEEE Trans. Software Eng.

Panichella

Zaidman

et al. 2018

Self Cite

Abstract-Code smells are symptoms of poor design or implementation choices that have a negative effect on several aspects of software maintenance and evolution, such as program comprehension or change-and fault-proneness. This is why researchers have spent a lot of effort on devising methods that help developers to automatically detect them in source code. Almost all the techniques presented in literature are based on the analysis of structural properties extracted from source code, although alternative sources of information (e.g., textual analysis) for code smell detection have also been recently investigated. Nevertheless, some studies have indicated that code smells detected by existing tools based on the analysis of structural properties are generally ignored (and thus not refactored) by the developers. In this paper, we aim at understanding whether code smells detected using textual analysis are perceived and refactored by developers in the same or different way than code smells detected through structural analysis. To this aim, we set up two different experiments. We have first carried out a software repository mining study to analyze how developers act on textually or structurally detected code smells. Subsequently, we have conducted a user study with industrial developers and quality experts in order to qualitatively analyze how they perceive code smells identified using the two different sources of information. Results indicate that textually detected code smells are easier to identify and for this reason they are considered easier to refactor with respect to code smells detected using structural properties. On the other hand, the latter are often perceived as more severe, but more difficult to exactly identify and remove.

Section: Refactoring Of Code Smellssupporting

confidence: 84%

The Scent of a Smell: An Extensive Comparison Between Textual and Structural Smells

IIEEE Trans. Software Eng.

Panichella

Zaidman

et al. 2018

Self Cite

“…In the Eclipse ecosystem we observed a consistent percentage of refactoring actions performed while fixing bugs; in this case, the differences with the other ecosystems are statistically significant and have a medium effect size when compared to Android and a large one when considering Apache. A similar result had been already noticed by Palomba et al [46], who showed that different refactoring activities aimed at improving both maintainability and comprehensibility of the source code are generally applied during bug fixing tasks. Such a scenario is particularly evident if we look the case of the Extract Method refactoring for Eclipse projects, where the commits tagged as bug fixing reach 38%.…”

Section: Rq3 Developer-oriented Factors and Refactoringsupporting

confidence: 82%

“…Specifically, the current development task (e.g., bug fixing, new feature implementation, feature enhancement) the developers' workload and the knowledge developers have about certain software components seem to be related to (i) the decision to refactor or not and (ii) which kind of refactoring operations to perform. These findings may represent an important starting point for researchers interested in devising new methodologies for adapting refactoring recommendations not only to the change type [46] but also to the characteristics of developers and the development time-frame of a project.…”

Section: Discussionmentioning

confidence: 83%

A large-scale empirical exploration on refactoring activities in open source software projects

Vassallo

Grano

Science of Computer Programming

et al. 2019

Self Cite

Refactoring is a well-established practice that aims at improving the internal structure of a software system without changing its external behavior. Existing literature provides evidence of how and why developers perform refactoring in practice. In this paper, we continue on this line of research by performing a large-scale empirical analysis of refactoring practices in 200 open source systems. Specifically, we analyze the change history of these systems at commit level to investigate: (i) whether developers perform refactoring operations and, if so, which are more diffused and (ii) when refactoring operations are applied, and (iii) which are the main developer-oriented factors leading to refactoring. Based on our results, future research can focus on enabling automatic support for less frequent refactorings and on recommending refactorings based on the developer's workload, project's maturity and developer's commitment to the project.

“…In particular, in the context of RQ1.1, we test whether JUnit test methods that contain a test smell are more likely to be change-or defect-prone. To this aim, we compute the Relative Risk (RR) [37], an index reporting the likelihood that a specific cause (in our case, the presence/absence of a test smell) leads to an increase in the amount a test case is subject to a particular property (in our case, number of changes or defects) [30], [58]. The RR is defined as the ratio of the probability of an event occurring in an exposed group (e.g., the probability of smelly tests being defective), to the probability of the event occurring in a non-exposed group (e.g., the probability of non-smelly tests being defective) and it is computed using the following equation:…”

Section: Discussionmentioning

confidence: 99%

On the Relation of Test Smells to Software Code Quality

Spadini

2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)

Zaidman

et al. 2018

Self Cite

112

108

Test smells are sub-optimal design choices in the implementation of test code. As reported by recent studies, their presence might not only negatively affect the comprehension of test suites but can also lead to test cases being less effective in finding bugs in production code. Although significant steps toward understanding test smells, there is still a notable absence of studies assessing their association with software quality.In this paper, we investigate the relationship between the presence of test smells and the change-and defect-proneness of test code, as well as the defect-proneness of the tested production code. To this aim, we collect data on 221 releases of ten software systems and we analyze more than a million test cases to investigate the association of six test smells and their co-occurrence with software quality. Key results of our study include:(i) tests with smells are more change-and defect-prone, (ii) 'Indirect Testing', 'Eager Test', and 'Assertion Roulette' are the most significant smells for change-proneness and, (iii) production code is more defect-prone when tested by smelly tests.