Software developers often need to repeat similar modifications in multiple different locations of a system's source code. These repeated similar modifications, or systematic edits, can be both tedious and error-prone to perform manually. While there are tools that can be used to assist in automating systematic edits, it is not straightforward to find out where the occurrences of a systematic edit are located in an existing system. This knowledge is valuable to help decide whether refactoring is needed, or whether future occurrences of an existing systematic edit should be automated. In this paper, we tackle the problem of finding unknown systematic edits using a closed frequent itemset mining algorithm, operating on sets of distilled source code changes. This approach has been implemented for Java programs in a tool called SysEdMiner. To evaluate the tool's precision and scalability, we have applied it to an industrial use case.

Change distilling algorithms compute a sequence of fine-grained changes that, when executed in order, transform a given source AST into a given target AST. The resulting change sequences are used in the field of mining software repositories to study source code evolution. Unfortunately, detecting and specifying source code evolutions in such a change sequence is cumbersome. We therefore introduce a tool-supported approach that identifies minimal executable subsequences in a sequence of distilled changes that implement a particular evolution pattern, specified in terms of intermediate states of the AST that undergoes each change. This enables users to describe the effect of multiple changes, irrespective of their execution order, while ensuring that different change sequences that implement the same code evolution are recalled. Correspondingly, our evaluation is two-fold. Using examples, we demonstrate the expressiveness of specifying source code evolutions through intermediate ASTs. We also show that our approach is able to recall different implementation variants of the same source code evolution in open-source histories.

Researchers in the field of Mining Software Repositories perform studies about the evolution of software projects. To this end, they use the version control system storing the changes made to a single software project. Such studies are concerned with the source code characteristics in one particular revision, the commit data for that revision, how the code evolves over time and what concrete, fine-grained changes were applied to the source code between two revisions. Although tools exist to analyse an individual concern, scripts and manual work is required to combine these tools to perform a single experiment. We present a general-purpose history querying tool named QwalKeko that enables expressing these concerns in a single uniform language, and having them detected in a git repository. We have validated our work by means of replication studies as well as through MSR studies of our own.

Functional testing requires executing particular sequences of user actions. Test automation tools enable scripting user actions such that they can be repeated more easily. SELENIUM, for instance, enables testing Web applications through scripts that interact with a Web browser and assert properties about its observable state. However, little is known about how common such tests are in practice. We therefore present a cross-sectional quantitative study of the prevalence of SELENIUM-based tests among open-source Web applications, and of the extent to which such tests are used within individual applications. Automating functional tests also brings about the problem of maintaining test scripts. As the system under test evolves, its test scripts are bound to break. Even less is known about the way test scripts change over time. We therefore also present a longitudinal quantitative study of whether and for how long test scripts are maintained, as well as a longitudinal qualitative study of the kind of changes they undergo. To the former's end, we propose two new metrics based on whether a commit to the application's version repository touches a test file. To the latter's end, we propose to categorize the changes within each commit based on the elements of the test upon which they operate. As such, we are able to identify the elements of a test that are most prone to change.

We present the QwalKeko meta-programming library for Clojure that enables querying the history of versioned software projects in a declarative manner. Unique to this library is its support for regular path expressions within history queries. Regular path expressions are akin to regular expressions, except that they match a sequence of successive snapshots of a software project along which user-specified logic conditions must hold. Such logic conditions can concern the source code within a snapshot, versioning information associated with the snapshot, as well as patterns of source code changes with respect to other snapshots. We have successfully used the resulting multi-faceted queries to detect refactorings in project histories. In this paper, we discuss how applicative logic meta-programming enabled combining the heterogenous components of QwalKeko into a uniform whole. We focus on the applicative logic interface to a new implementation of a well-known change distilling algorithm. We use the problem of detecting and categorizing changes made to Selenium-based test scripts for illustration purposes.