当测试持续通过，但设计停滞不前

Source: Dev.to

设计停滞问题

在实践 TDD 时，我经常遇到这样一个时刻：测试通过，覆盖率提升，重构感觉很安全。然而，到了某个节点，设计却不再前进。并不是因为系统已经完成或问题已经解决，而是因为测试不再对任何东西提出挑战。它们只是在确认已经锁定的决定。

这种停滞是微妙的——表面上没有明显错误，但学习速度已经降到爬行。每一个新测试都显得必然，系统仍在变化，只是局限在很久以前设定的边界之内。

测试角色的转变

我并不认为这是因为我们写错了测试。它发生在测试悄悄转变角色的时候。起初，测试是探索性的，但随着时间推移，许多测试变成了别的东西。当这种情况出现时，一个绿色测试不再降低疑虑，即使反馈回路仍在运行。

回顾过去，令我惊讶的不是设计停滞，而是一些假设过早固化——往往并未明确设计出来：

• 类的边界
• 数据结构
• 集成点
• 测试愿意断言的内容——以及它们没有断言的内容

一旦这些假设被深深编码进去，设计工作并没有真正停止，只是不再感觉有必要去做。

重新点燃设计的实验

这种领悟促使我进行了一些不太舒服的实验：

• 编写在看似合理之前就进行端到端的测试。
• 少从功能角度思考，更多关注无论系统如何演化都绝不能破坏的东西。
• 留意实际对我产生了哪些变化。

通常，转变并不是对正确性的信心问题；而是我不再觉得需要质疑设计的时刻。这并不是在为更多测试辩护。关键不在于测试放在哪里，而在于它施加了何种压力。有些测试只验证部件是否能拼在一起；这些冲突虽然让人不适，却也是设计再次前进的地方。

这不是…

这并不是在主张测试应该取代设计工作。它是一种观察：某些假设在纸面上看起来很稳固，在这种情况下，特定的测试并不能替代设计。

在 AI 辅助编码时代的影响

最近，这个问题显得更为紧迫。借助 AI 辅助编码，生成看似合理的实现、通过测试、进行说服性的重构变得轻而易举。绿色测试变得廉价，这让假设更容易在不被察觉的情况下沉淀。如果测试只是在确认结构，那么真正的问题就变成了：

谁仍然负责发现设计何时停止前进？

重新构建测试与设计的关系

我并不是在提出一种新方法论；我只是在提供一种重新框架的视角。设计并不是在测试之前的一个阶段。在最有用的形式下，测试是怀疑的工具。当测试不再发挥这一作用时，就意味着出现了问题，接下来的工作是寻找前进的道路。

绿色测试并不意味着“这部分是正确的”。有时它仅仅意味着某个假设已经悄然不再被质疑。当设计停止前进时，这正是我仍在努力理解的部分。