我测量了AI编写空心测试是否比人类更严重，结果并非如此

在现代软件开发中，自动化测试、类型检查和持续集成（CI）门禁被视为保障代码质量的重要防线。然而，这些防线本身也可能存在缺陷——它们可能看似存在并且运行正常，但实际上从未验证任何东西。这种“空心”守卫比完全没有守卫更加危险，因为它们给人一种虚假的安全感。最近，一位开发者通过分析一个代码仓库，发现了七个这样的空心守卫，并由此开发了一个新的开源工具voidguard，专门用于检测这类问题。

voidguard能够识别四种类型的空心守卫。第一种是“从未运行的测试”，这些测试被环境标志或CI配置跳过，但实际上没有在任何地方真正执行。第二种是“不检查任何东西的类型门”，例如配置错误的mypy或tsconfig，它们声称正在执行类型检查，但由于配置缺陷实际上没有检查任何有效代码。第三种是“被静默丢弃的设置”，比如在Python脚本中设置的PYTHON*变量被命令行参数覆盖而失效，或者在Docker构建中定义的ARG在错误的位置被使用。第四种是“永远无法触发的CI条件”，例如CI工作流的触发条件引用了永远不会发生的事件，或者计划任务从未成功运行。对于每种检测到的空洞，voidguard会给出一个明确的判定：VOID（空洞）、WARN（警告）或UNKNOWN（无法确定），并附带详细的搜索范围信息。

尽管voidguard很强大，但它并非万能。作者明确指出，该工具无法检测三种类型的空洞。首先是“语义空洞”，例如一个字段类型被标记为可空但实际从未被写入值，或者一个函数返回null但调用方将其当作有效值。这类问题需要类型流或数据流分析，而不仅仅是文件结构分析。其次是“流程空洞”，例如一个需要人工审批的步骤在合并过程中被绕过，而所有自动化检查都显示为绿色。没有任何扫描工具能够捕捉到这种人为决策的缺失。最后是“需要执行才能发现的空洞”，voidguard本身从不运行代码，所以它无法发现那些在运行时才会暴露的错误。当静态分析无法确定时，voidguard会诚实地返回UNKNOWN并解释原因，因为一个声称发现空洞却自己产生误报的工具本身就是一个空心守卫。

voidguard的诞生源于一个具体的案例。在一个仓库的一次性扫描中，作者发现了七个空心守卫：一个核心完整性测试从集成开始就默默地被跳过，一个类型检查门禁实际上没有检查任何内容，一个审批步骤被合并操作直接绕过。所有这些守卫的CI状态都是绿色的，但它们的实际验证效果为零。voidguard正是这种扫描方法的通用化实现。这个工具已经发布在PyPI上，源代码也在GitHub上公开。它不仅是一个实用的检测工具，更传达了一个重要的理念：在自动化测试和验证中，我们必须验证验证本身的有效性，否则那些绿色状态只能带来虚假的安全感。