北京
项目覆盖率表里有一行，显示的是0/13。过了一阵子，它变成了0/19。整整一天，每次提交它都是零，我每次看到都没停下来，因为零就是我预期的数字——那项工作本来就没做完。未完成的工作显示红色，不算新闻。
但这行其实什么都没测到。问题出在负责这项检查的crate里的一行代码：
pub const SEMANTIC_MAPS: &str = "UnderstandRTSync/semantic";
这个路径是相对于仓库根目录解析的。它指向的目录根本不在仓库里面，而是仓库的兄弟目录。于是读取器打开了一个不存在的路径，找不到任何文件，然后在一个空集合上诚实地做了算术。十三分之零。后来有人添加了crate，变成了十九分之零，看起来更像是一个项目在缓慢推进。
分母在动，分子却永远动不了，而整个环境里没有任何东西能告诉我这一点。
为什么它没被发现
它活下来，是因为旁边两行红得有理有据。一个文件台账是0/289，一个文档清册是0/1916，都是真正的大工程刚起步的状态。
一个预期的红色，藏在一排预期的红色中间。我的审查把这张表当成进度条在读，问的是数字有没有在动，而不是这个测量工具本身能不能产生一个非零的数字。
一般规律是：一个永远只会失败的检查，和一个正在失败的检查，看起来完全一样。而这两者的区别，比面板上任何一个单独的判定都重要。
修复只花了一行，测试才是关键
把路径指到正确的目录，只需要一行代码。但那不是最有趣的部分。跟着一起加进去的测试是这样的：
#[test]fn semantic_map_coverage_counts_the_maps_it_can_see()
它的注释把判别标准说得很清楚：指向空目录时，必须读出0/n；指向只有一个map的目录时，必须读出1/n；指向真实目录时，必须读出磁盘上map的确切数量。这样一来，"永远报零的覆盖率"和"永远报n/n的覆盖率"就变成了两种不同的、可见的失败。
环境变量存在的唯一目的，就是让测试能在工具的脚下移动目录。真实目录里到底有多少文件，测试从不断言，因为那个数字是项目自己的事，每天都在变。
分母也不再靠手数了
还有一件事跟着改了。分母以前是手工维护的文件计数，现在直接从Cargo.toml里的workspace成员推导。新增crate会自动抬高分母，不需要任何人记得去更新一个列表。一个靠手工维护的分母，是一个永远会顺着我的分母。
我早就写过一条规则："每个控制项都需要一个植入的负例"，并且一直遵守。这个项目上的每项检查，都有一个必须让它变红的用例。
但我没有为相反的方向立过规则，这一行就是那个缺口的样子：一个检查，从来没有被展示过一个它应该说非零数字的世界。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
