Blessing or Curse? Investigating Test Code Maintenance Through Inheritance and Interface
Bibliographic record
Abstract
Since the advent of object-oriented programming languages, inheritance and interface have been fundamental concepts in software design principles, facilitating code reuse and extensibility in software systems. Despite their potential benefits, inheritance, and interface remain underexplored in software test code. Currently, there is a limited established standard for how inheritance and interface may impact test reusability, extensibility, and maintainability, nor for understanding the potential design challenges that may arise from improper usage. Addressing these research gaps is crucial for optimizing test maintainability and software quality. In this paper, we address this gap in empirical research by conducting the first comprehensive study on the prevalence and maintenance of inheritance and interface within test code. To accomplish this goal, we use RefactoringMiner's AST differencing API to detect inheritance and interface changes in modified test classes within the software evolution commit history by studying 12 open-source Java systems. Our key findings are as follows: (1) Among the 23,651 commits that modify test classes, 4,429 (18%) involve changes to their inheritance relationships, whereas a significantly smaller subset, 233 (1%), pertain to changes in their interface relationships. (2) 59.5% of test classes already incorporate inheritance when initially created, while 40% of test classes incorporate interfaces. (3) We manually categorized the use of inheritance and interfaces and their impact on test maintainability to provide valuable insights for developers. In summary, this study takes the first step in exploring how the use of inheritance and interfaces in test code affects software reusability and extensibility, offering meaningful insights for both developers and researchers
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.007 | 0.080 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.006 | 0.003 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.002 | 0.004 |
| Open science | 0.001 | 0.002 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.001 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".