测试基座应该早于复杂功能扩展

源生成器项目里，有一种很常见的拖延：

先把功能都做完，测试以后再补。

这在普通业务代码里已经不太稳，在生成器里会更危险。

为什么生成器特别容易积累“静默回归”

因为很多回归不是运行时报错，而是：

• 生成内容悄悄变了
• 诊断 ID 变了
• 某个配置键不再生效
• 某种嵌套或泛型场景突然不命中

这些问题如果没有测试，你通常只能靠 sample 手工看结果。

而 sample 最擅长的，从来不是覆盖边界。

复杂功能为什么更依赖测试基座

当你开始补下面这些能力时，测试就不再是“可选增强”：

• AdditionalFiles
• 多配置文件合并
• 显式消息键
• build_property.*
• analyzer 与 generator 协同

因为这些能力都有一个共同点：

输入组合一多，靠肉眼验证几乎不可能稳定。

更稳的顺序是什么

比起“先做完功能再回头补测试”，更稳的顺序通常是：

1. 先立最小测试基座
2. 再补第一批复杂边界
3. 每加一层配置或诊断，就补对应断言

这样你扩的是能力，不是在滚着扩风险。

enterprise 为什么必须带测试项目

如果模板已经走到 enterprise，说明它的目标不是演示，而是交付。

一旦目标是交付，测试就不只是保障代码质量，而是保障模板复制出去以后还能保持同样边界。

换句话说，测试基座保护的不是某一次实现，而是模板契约本身。

一句话结论

对源生成器模板来说，测试基座最合理的位置不是“最后补”，而是“复杂功能开始增加之前就先立住”。