chimera-test-the-wiring-not-the-class

你做了一个生产环境间接到达的组件：通过工厂、注册表、插件加载器、配置开关、路由器、CLI 入口，或者一个依赖注入容器。而你的测试是直接构造它、直接调用它的方法。

这些测试每一个都可能通过，同时这个组件在运行中的系统里根本无法到达——因为它们当中没有任何一个演练过注册动作、开关的默认值，或者组装器里那个决定要不要把它包含进来的分支。

对于调用方直接 import 并调用的纯函数，这条不适用。在那里，import 就是接线，一个单元测试就覆盖了它。当你是刻意在隔离环境中测试一个算法时，这条也不适用——那些测试是正确的，应该保留；这张卡片说的是它们单靠自己不够。

1. 点名一个用户真正会碰到的入口：那个 CLI 子命令、那条 HTTP 路由、agent 的运行循环、那个定时任务。在写测试之前先把它写下来。

2. 至少写一个从那里出发、并且不为你的组件传入任何构造参数的测试。如果测试必须点名你的类才能让这个功能发生，那它测的就不是接线。

3. 按生产环境构建对象的方式去构建它——调用真正的工厂或配置加载器：

   # 错——证明的是这个类，不是接线：组件是被交给被测对象的，
   # 所以不管生产环境里有没有任何东西真的把它交出去，测试都会通过。
   assert "reminder" in render(feature=Feature(text="reminder"))
   
   # 对——按入口构建它的方式去构建，然后去找同一个可观察的东西
   assert "reminder" in build_the_real_way(config).render()
   

   Chimera 自己的例子值得点名，因为那个类从来就没坏过。skill card 有一个能用的检索器、一个能用的存储和一个能用的注入器——而 chimera/config.py:244 写的是 skill_cards: bool = Field(default=False, ...)，所以在一个原样部署的环境里，从来没有任何东西被注入过。每一个单元测试都通过。最终抓到它的那次测量，数了铸出的 skill 数和注入的 skill 数，得到的是 39 比零。

4. 断言一个只有在组件确实被到达时才可能出现的可观察物：渲染出的提示词里的文字、写下的一行记录、一条日志、一个退出码。

5. 断言默认值。如果这个功能是藏在一个开关后面发布的，就再加一个测试，在没有任何覆盖的情况下读取那个默认值，并断言它是什么。一套永远只在开关被强制打开的情况下运行的测试，没法告诉你用户拿到的是什么。

入口测试更慢、更难调试，定位也更差：一个失败时你知道这个功能坏了，但不知道是十个组件里的哪一个把它弄坏的。这是真实的代价，而对这张卡片的错误反应，是删掉单元测试改用端到端测试。两个都留着——接线测试告诉你它坏了，单元测试告诉你坏的是什么。

走真正的入口，也可能碰到你不想在 CI 里碰的东西：一个要付费的 API、一个线上数据库、沙箱之外的文件系统。如果到达入口的唯一办法是花钱或者改动生产环境，那就别硬来；改成直接覆盖那个组装函数，并接受你离真实路径还差一步。

还有，这张卡片抓的是可达性，不是正确性。一个功能可以完美地接到入口上，却依然给出错误的答案，所以一个绿色的接线测试，并不是跳过断言输出内容的许可证。