60 个单测跑完,59 绿 1 红。红的那个,测的是最不起眼的能力:递归扫描目录,要能找到埋在子目录深处的文件。
这种红值得记一笔,因为它和"某个逻辑断言挂了"不是同一类失败。
枚举型测试比普通单测多依赖一层东西:文件系统在测试宿主上的实际行为。所以六十个用例里恰好只有枚举这一个红了,第一问不该是"递归写错了吗",而是"哪一层坏了":遍历逻辑、测试夹具,还是枚举原语本身。跳过归因直接改遍历代码,等于把环境问题修进业务代码里。
排查顺序,便宜的在前:
1. 换一个独立工具对同一棵目录树做同样的枚举(find、ls -R),用同一个身份跑。这叫对照证据,不叫"再跑一次测试"——如果 find 也漏、也卡,嫌疑就不在你的遍历器。 2. 原语坏了,先怀疑机器。macOS 上有个反复出现的签名:目录枚举失败,而按路径打开文件照常成功,因为两者走的不是同一条路;卷容量见底时,枚举会比其他一切先坏,重启用户态服务救不回来。换句话说,"能找到嵌套文件"这个测试意外成了一台机器的健康哨兵——它踩中的失败模式,另外 59 个用例根本看不见。 3. 原语正常,才轮到遍历逻辑。惯犯有两个:先按扩展名过滤再递归(目录永远不匹配后缀,整棵子树被剪掉);把符号链接或 bundle 当叶子,不再往下走。
一分钟自检,今天就能对自己的代码跑一遍:在你程序会扫描的目录里往第三层子目录放一个文件,数你的代码找到了几个,再数 find 找到几个。两边一致,遍历没问题;只在你的进程里数不一致,是沙箱或权限的形状;连 find 都报错,是机器在求救。
最后一条纪律:红色的分布本身就是证据。全部绿、唯独枚举红,和零零散散几个红,指向的层完全不同——先读图案,再动手。