Recent research has shown that clones occur far more often in test code than in production code. This is explained by the typical template of unit test code (the setup-stimulate-verify-teardown cycle), a template which lends itself well to parameterisation of proven solutions. However, little is known on how these clones evolve over time. In this paper, we compare the evolution of clones in test code with those in production code. Based on a quantitative and qualitative study of eight representative open-source systems, we conclude that clones in test code are inherently different than clones in production code throughout development. As a consequence, consistent maintenance and tracking of test clones becomes more important, hence the need for special purpose clone tracking and management tools.

Re-using whole repositories as a starting point for new projects is often done by maintaining a variant fork parallel to the original. However, the common artifacts between both are not always kept up to date. As a result, patches are not optimally integrated across the two repositories, which may lead to sub-optimal maintenance between the variant and the original project. A bug existing in both repositories can be patched in one but not the other (we see this as a missed opportunity) or it can be manually patched in both probably by different developers (we see this as effort duplication). In this paper we present a tool (named PaReCo) which relies on clone detection to mine cases of missed opportunity and effort duplication from a pool of patches. We analyzed 364 (source to target) variant pairs with 8,323 patches resulting in a curated dataset containing 1,116 cases of effort duplication and 1,008 cases of missed opportunities. We achieve a precision of 91%, recall of 80%, accuracy of 88%, and F1-score of 85%. Furthermore, we investigated the time interval between patches and found out that, on average, missed patches in the target variants have been introduced in the source variants 52 weeks earlier. Consequently, PaReCo can be used to manage variability in “time” by automatically identifying interesting patches in later project releases to be backported to supported earlier releases.

Duplicated test code (a.k.a. test code clones) has a negative impact on test comprehension and maintenance. Moreover, the typical structure of unit test code induces structural similarity, increasing the amount of duplication. Yet, most research on software clones and clone detection tools is focused on production code, often ignoring test code. In this paper we fill this gap by comparing four different clone detection tools (NiCad, CPD, iClones, TCORE) against the test code of three open-source projects. Our analysis confirms the prevalence of test code clones, as we observed between 23% and 29% test code duplication. We also show that most of the tools suffer from false negatives (NiCad = 83%, CPD = 84%, iClones = 21%, TCORE = 65%), which leaves ample room for improvement. These results indicate that further research on test clone detection is warranted.

Code clones commonly occur during software evolution. They impact the effort of software development and maintenance, and therefore they need to be monitored. We present a large-scale empirical study (237 open-source Java projects maintained by 500 individuals) that investigates how the number of clones changes throughout software evolution, as well as the tendency of individual developers to introduce clones. Our results will set a point-of-reference against which development teams can compare and, if needed, adjust.