2026-10-05T21:32:38Z https://drops.dagstuhl.de/oai

oai:drops-oai.dagstuhl.de:28004 2026-10-05T06:44:04Z ddc:004 open_access

Is Self-Admitted Technical Debt Tested? An Empirical Study of Coverage, Co-Change, and Impact Yoshimoto, Suzuka Horikawa, Kosei Feitosa, Daniel Kashiwa, Yutaro Iida, Hajimu Self-Admitted Technical Debt Test Coverage Software Testing Background. When developers write a TODO or FIXME comment, they are explicitly admitting that the code is suboptimal: a built-in warning that this logic deserves extra scrutiny. Yet it is an open question whether Self-Admitted Technical Debt (SATD) actually receives that scrutiny in the form of software testing. Aim. We aim to characterize the relationship between SATD and testing across three dimensions: the extent to which SATD-affected code is covered by existing tests, whether developers synchronize test additions with debt resolution, and whether such testing affects the long-term observability of resulting defects. Method. For that, we conducted an empirical study on eight open-source Java projects, analyzing test coverage of 784 SATD instances identified in the latest releases and performing a longitudinal examination of 5,175 SATD removal events. Results. Our results show that while 60.7% of SATD-affected code is covered by existing test suites, developers rarely synchronize test modifications with debt resolution; manual inspection confirms that only 3.4% of SATD removal commits include new tests specifically targeting the resolved debt (vs. 12.5% that co-add tests in the same commit). Longitudinal analysis further suggests that SATD resolutions exhibit nearly identical localized bug induction rates within short-to-medium-term windows regardless of test modifications. However, over a longer, unrestricted observation window, a slight divergence emerges where the test-added group reaches a higher cumulative defect alignment probability (6.32% vs. 4.37%), a counterintuitive trend potentially driven by the selective testing of inherently complex components. Conclusion. Developers treat SATD repayment as an ordinary code change rather than as a high-risk maintenance activity: most debt removals proceed without targeted verification, despite the developer’s own prior flag that the code is suboptimal. Schloss Dagstuhl – Leibniz-Zentrum für Informatik Suzuka Yoshimoto and Kosei Horikawa and Daniel Feitosa and Yutaro Kashiwa and Hajimu Iida 2026 Is Part Of LIPIcs, Volume 394, 20th International Symposium on Empirical Software Engineering and Measurement (ESEM 2026) InProceedings Text doc-type:ResearchArticle publishedVersion application/pdf doi:10.4230/LIPIcs.ESEM.2026.36 urn:nbn:de:0030-drops-280048 https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.ESEM.2026.36 eng https://creativecommons.org/licenses/by/4.0/legalcode