Quinten David Soetens

Studying the Effect of Refactorings: A Complexity Metrics Perspective

Refactoring is widely recognized as a way to improve the internal structure of a software system in order to ensure its long-term maintainability. Consequently, software projects which adopt refactoring practices should see reductions in the complexity of their code base. We evaluated this assumption on an open source system —namely PMD, a Java source code analyzer— and discovered that periods of refactorings did not affect the cyclomatic complexity. This paper investigates this counterintuitive phenomenon through a detailed analysis of the actual source code manipulations applied on the system under study.

Comparison of similarity metrics for refactoring detection

Identifying refactorings in software archives has been an active research topic in the last decade, mainly because it is a prerequisite for various software evolution analyses (e.g., error detection, capturing intent of change, capturing and replaying changes, and relating refactorings and software metrics). Many of these techniques rely on similarity measures to identify structurally equivalent code, however, up until now the effect of this similarity measure on the performance of the refactoring identification algorithm is largely unexplored. In this paper we replicate a well-known experiment from Weißgerber and Diehl, plugging in three different similarity measures (text-based, AST-based, token-based). We look at the overlap of the results obtained by the different metrics, and we compare the results using recall and the computation time. We conclude that the different result sets have a large overlap and that the three metrics perform with a comparable quality.

ChEOPSJ: Change-Based Test Optimization

Software is an ever-changing entity and frequently executed unit tests are the primary means to increase the confidence that the changed system continues to work as expected. Executing an entire test suite however can take a significant amount of time - much longer than developers are willing to wait before tackling the next change action. We demonstrate how our tool prototype ChEOPSJ may alleviate this problem by adopting a change-centric approach. Our tool sits in the back of Eclipse and captures all changes made in the main editor while the developer is programming. The changes and the dependencies between them are analyzed to deduce which unit tests are relevant for a selected sequence of changes.

Change-based test selection: an empirical evaluation

Regression test selection (i.e., selecting a subset of a given regression test suite) is a problem that has been studied intensely over the last decade. However, with the increasing popularity of developer tests as the driver of the test process, more fine-grained solutions that work well within the context of the Integrated Development Environment (IDE) are in order. Consequently, we created two variants of a test selection heuristic which exploit fine-grained changes recorded during actual development inside the IDE. One variant only considers static binding of method invocations while the other variant takes dynamic binding into account. This paper investigates the tradeoffs between these two variants in terms of the reduction (i.e., How many tests could we omit from the test suite, and how much did we gain in runtime execution?) as well as the fault detection ability of the reduced test suite (i.e., Were tests omitted erroneously?). We used our approach on three distinct cases, two open source cases —Cruisecontrol and PMD— and one industrial case — Historia. Our results show that only considering static binding reduces the test suite significantly but occasionally omits a relevant test; considering dynamic binding rarely misses a test yet often boils down to running the complete test suite. Nevertheless, our analysis provides indications on when a given variant is more appropriate.

Mutation testing as a safety net for test code refactoring

Refactoring is an activity that improves the internal structure of the code without altering its external behavior. When performed on the production code, the tests can be used to verify that the external behavior of the production code is preserved. However, when the refactoring is performed on test code, there is no safety net that assures that the external behavior of the test code is preserved. In this paper, we propose to adopt mutation testing as a means to verify if the behavior of the test code is preserved after refactoring. Moreover, we also show how this approach can be used to identify the part of the test code which is improperly refactored.

Considering Polymorphism in Change-Based Test Suite Reduction

With the increasing popularity of continuous integration, algorithms for selecting the minimal test-suite to cover a given set of changes are in order. This paper reports on how polymorphism can handle false negatives in a previous algorithm which uses method-level changes in the base-code to deduce which tests need to be rerun. We compare the approach with and without polymorphism on two distinct cases ---PMD and CruiseControl--- and discovered an interesting trade-off: incorporating polymorphism results in more relevant tests to be included in the test suite (hence improves accuracy), however comes at the cost of a larger test suite (hence increases the time to run the minimal test-suite).

Circumventing refactoring masking using fine-grained change recording

Today, refactoring reconstruction techniques are snapshot-based: they compare two revisions from a source code management system and calculate the shortest path of edit operations to go from the one to the other. An inherent risk with snapshot-based approaches is that a refactoring may be concealed by later edit operations acting on the same source code entity, a phenomenon we call refactoring masking. In this paper, we performed an experiment to find out at which point refactoring masking occurs and confirmed that a snapshot-based technique misses refactorings when several edit operations are performed on the same source code entity. We present a way of reconstructing refactorings using fine grained changes that are recorded live from an integrated development environment and demonstrate on two cases ---PMD and Cruisecontrol--- that our approach is more accurate in a significant number of situations than the state-of-the-art snapshot-based technique RefFinder.

Avoiding bugs pro-actively by change-oriented programming

To minimize the cost of fixing bugs, they need to be identified as soon as possible. Testing the system is a means to detect such defects. However, when all the tests are run, it is often difficult to locate the precise error that causes a test to fail. We propose to use change-oriented programming as a means to detect bugs in a system while it is being developed. Not only may this technique assists in detecting bugs sooner, it can also be used to provide the developer with fine-grained information about the places in the program and test code that relate to the defect. We believe that this will decrease the probability of introducing bugs in a system and speed up the detection of the bugs that do get in.

Changes as First-Class Citizens: A Research Perspective on Modern Software Tooling

Software must evolve to keep up with an ever-changing context, the real world. We discuss an emergent trend in software evolution research revolving around the central notion that drives evolution: Change. By reifying change, and by modelling it as a first-class entity, researchers can now analyse the complex phenomenon known as software evolution with an unprecedented degree of accuracy. We present a Systematic Mapping Study of 86 articles to give an overview on the state of the art in this area of research and present a roadmap with open issues and future directions.

Change-based FODA diagrams: bridging the gap between feature-oriented design and implementation

Feature Oriented Design Analysis (FODA) diagrams present the design of feature-oriented software applications. In some cases, however, the actual implementation of such an application does not correspond to the design that was set forward by the FODA diagram. Such discrepancies are referred to as the gap between design and implementation. We present a bottom-up approach for generating FODA diagrams from the changes to the source code. Unlike ordinary FODA diagrams, those diagrams are based on the implementation. Thanks to that, they do not only contain coarse-grained design information, but also incorporate finegrained implementation details, which can be used to bridge between feature-oriented design and implementation.