Systematic Testing of Refactoring Engines on Real Software Projects

Gligoric, Milos; Behrang, Farnaz; Li, Yilong; Overbey, Jeffrey; Hafiz, Munawar; Marinov, Darko

doi:10.1007/978-3-642-39038-8_26

Cited by 27 publications

(27 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As in the previous case, we suppose that the constructor call does not take any argument or take attainable ones. This local variable is removed from the method body and turned into a private field of the class (this refactoring, transforming a local variable to a field, is failure-safe as it has been experimented in the literature [9]). This field will be treated following the previous case.…”

Section: Moving a Constant Declarationmentioning

confidence: 99%

Refactoring Object-Oriented Applications towards a better Decoupling and Instantiation Unanticipation

Zellagui¹,

Tibermacine²,

Bouziane³

et al. 2017

International Conferences on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

Modularity in Object-Oriented (OO) applications has been a major concern since the early years of OO programming languages. Migrating existing OO applications to Component-Based (CB) ones can contribute to improve modularity, and therefore maintainability and reuse. In this paper, we propose a method for source code transformation (refactoring) in order to perform this migration. This method enhances decoupling by considering that some dependencies between classes should be set through abstract types (interfaces) like in CB applications. In addition, some anticipated instantiations of these classes "buried" in the source code are extracted and replaced by declarative statements (like connectors in CB applications) which are processed by a dependency injection mechanism. For doing so, a set of "Bad Smells", i.e., modularity-violating symptoms, has been defined. These are first detected in the source code. Then, some refactoring operations are applied for their elimination. An implementation of the method was successfully experimented on a set of open source Java projects. The results of this experimentation are reported in this paper.

show abstract

Section: Moving a Constant Declarationmentioning

confidence: 99%

Refactoring Object-Oriented Applications towards a better Decoupling and Instantiation Unanticipation

Zellagui¹,

Tibermacine²,

Bouziane³

et al. 2017

International Conferences on Software Engineering and Knowledge Engineering

View full text Add to dashboard Cite

show abstract

“…In this case, the variational data structures remain invariable, and accesses to them can be handled without consulting BDDs or a SAT solver. Finally, to obtain a proper test suite, we parametrized each refactoring pattern based on a previous test setup for refactoring engines as follows [24]: Renaming Identifier: For each file, we randomly selected up to 50 identifiers (e.g., function names, local or global identifiers, user-defined data types), and renamed them using a predefined name. Each selected identifier was annotated with at least 1 configuration option (up to 27 options) and its renaming affected multiple configurations (Table II).…”

Section: B Experiments Setupmentioning

confidence: 99%

“…To this end, we randomly selected sequences of statements (up to 100 selections, similar to Gligoric et al [24]) from a function's implementation that contain variability in form of #ifdef annotated statements. In our experiments, the selected statement sequences were partially annotated with at least 1 and up to 18 configuration options.…”

Section: B Experiments Setupmentioning

confidence: 99%

“…For each subject system, we used a substantial test suite to provide evidence for the correctness of our refactoring engine. For this purpose, we extended a standard approach of testing refactoring engines [16], [24], [54] with support for variability.…”

Section: Introductionmentioning

confidence: 99%

“…To this end, we extend a standard approach of testing refactoring engines [16], [24], [54] with support for variability.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Morpheus: Variability-Aware Refactoring in the Wild

Liebig

Apel

Janker

et al. 2015

2015 IEEE/ACM 37th IEEE International Conference on Software Engineering

View full text Add to dashboard Cite

Abstract-Today, many software systems are configurable with conditional compilation. Just like any software system, configurable systems need to be refactored in their evolution, but their inherent variability induces an additional dimension of complexity that is not addressed well by current academic and industrial refactoring engines. To improve the state of the art, we propose a variability-aware refactoring approach that relies on a canonical variability representation and recent work on variability-aware analysis. The goal is to preserve the behavior of all variants of a configurable system, without compromising general applicability and scalability. To demonstrate practicality, we developed MORPHEUS, a sound, variability-aware refactoring engine for C code with preprocessor directives. We applied MORPHEUS to three substantial real-world systems (BUSYBOX, OPENSSL, and SQLITE) showing that it scales reasonably well, despite of its heavy reliance on satisfiability solvers. By extending a standard approach of testing refactoring engines with support for variability, we provide evidence for the correctness of the refactorings implemented.

show abstract