Problem
Research questions and friction points this paper is trying to address.
Self-Admitted Technical Debt
Software Testing
Test Coverage
Defect Observability
Is Self-Admitted Technical Debt Tested? An Empirical Study of Coverage, Co-change, and Impact
🤖 AI Summary
研究探讨了自认技术债务（SATD）与软件测试的关系，通过分析八个开源Java项目中的784个SATD实例及5,175次移除事件，发现尽管60.7%的SATD代码被现有测试覆盖，但开发者很少同步更新测试以解决债务问题。
📝 Abstract
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. 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. 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. 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. 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.
Innovation
Methods, ideas, or system contributions that make the work stand out.
Self-Admitted Technical Debt
test coverage
co-change of tests and debt resolution
long-term defect observability
🔎 Similar Papers
No similar papers found.
