A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

软件永远不会真正完成。即使在程序发布之后，开发人员也必须不断地回到它面前，去修复错误、添加新功能并适应变化的需求。这种持续性的工作被称为维护，它往往比软件最初的创建过程需要更多的精力。为了使这项工作变得可控，程序员有时会在代码中留下注释，承认某个特定部分很混乱、是临时的或不太正确。他们可能会写下一句注释说，“这是一个权宜之计（hack）”，或者“稍后修复此项”。在软件工程领域，这些诚实的承认被称为“自我承认的技术债”。它们就像开发者在说：“我知道这不是最好的做法，但我们现在必须把它做完。”虽然研究人员长期以来一直在研究运行程序的主代码中的这些注释，但他们很大程度上忽略了用于测试该程序的代码中所发现的注释。这是一个重大的疏忽，因为如果测试本身存在缺陷或编写拙劣，整个软件系统就会变得不可靠。

曼尼托巴大学的一个研究小组致力于理解这一隐藏的债务层。他们专注于一种用 Java 编写的特定类型软件，Java 是一种广泛用于构建复杂应用程序的语言。为了获得清晰的图景，他们收集了一个包含超过一百万条注释的一千个不同开源项目的庞大集合。从这个巨大的资源池中，他们随机选择了五万条注释进行人工检查。这项手动审查工作非常艰苦，需要研究人员阅读每一条注释，并判断它代表的是一个真正的故障承认，还是仅仅是一个标准的解释。在过滤掉不相关或来自单一项目（从而导致数据偏差）的注释后，他们确定了 615 条属于测试代码中真实技术债的注释。

研究人员发现，这些存在于测试代码中的债务性质与在主应用程序代码中发现的债务截然不同。他们将这 615 个实例分成了 11 个不同的类别。其中一些是大家熟悉的，例如关于设计拙劣或文档缺失的注释。然而，有四个类别是完全针对测试领域而全新的。这些类别包括：“有限测试（limited tests）”，即开发者承认该测试仅检查了问题中极小且不具代表性的部分；“跳过测试（skip tests）”，即一个测试因为无法在当前环境中运行而被显式关闭；“挂起（on-hold）”，即一个测试在等待外部工具或服务可用；以及“不确定性（uncertainty）”，即开发者不确定该测试是否正确。这一分类法揭示了测试代码承载着其独特的负担，这些负担通常与验证软件行为的特定挑战有关，而非构建软件本身。

在绘制出这些债务的样貌后，团队提出了第二个更具实际意义的问题：计算机能否自动发现它们？他们测试了七种现有的旨在识别常规源代码中此类注释的工具。他们还测试了一系列人工智能模型，包括开源模型和来自大型科技公司的强大专有系统。结果令人惊讶。依赖于寻找如“TODO”或“FIXME”等特定关键词的现有工具，在传统方法中表现最好，但它们仍然漏掉了超过三分之一的实际债务。它们在发现问题时准确率较高，但在发现问题的数量上却力有不逮。

人工智能模型的表现则在不同方面表现得更差。开源模型难以发现这些债务，除非注释中包含非常明显的关键词，否则它们经常无法识别。当它们发现问题时，也经常出错。被认为更为先进的专有模型则表现出相反的问题。它们几乎找到了每一个债务，但也将数百条无害的注释标记为问题。它们过于渴望寻找问题，以至于将常规的解释误认为是失败的承认。最终，无论是传统工具还是最先进的 AI 系统，都无法可靠地检测出这些测试代码中的债务。

研究结论指出，开发人员在测试代码中描述问题的方式与在主代码中描述问题的方式有着本质的区别。测试文件中的注释经常使用测试过程特有的语言，例如提到一个测试被“禁用（disabled）”或“跳过（skipped）”，而标准的工具和 AI 模型并不能将这些识别为债务的信号。研究人员发现，现有的方法尚不足以处理这种复杂性。他们创建了一个新的数据集和一个详细的债务类型图谱，以帮助未来的研究人员构建更好的检测工具。在此之前，寻找并修复这些隐藏在测试代码中的缺陷，仍然是一项需要人类关注的工作。