1 分钟阅读
每个工具都自带测试
单人开发者如何在不拖慢节奏的前提下，靠测试纯逻辑和关键交互，让小工具保持可靠。
一个小工具箱很容易腐烂。一次重构改了正则，文本计数器就在中文输入上悄悄失效。对单人开发者来说，唯一能扩展的防御，就是每次改动都跑一遍的测试。
两层，不是五层
我不追覆盖率百分比。我只希望每个工具满足两件事：
- 纯逻辑被测试。 计数、格式化、时区运算——这些是没有 DOM 的函数，可以轻松测透。
- 主交互被测试。 输入内容、点 Format、看到结果、点 Copy。这些测试能抓住纯逻辑测试抓不到的接线错误。
it("updates counts as the user types", () => {
fireEvent.change(input, { target: { value: "Hello world" } });
expect(statValue("Words")).toBe("2");
});
哪些刻意不做单元测试
有些行为无法在无头 DOM 里跑。真实的 canvas 图片压缩、真实的二维码渲染、真实的浏览器时区数据。对这些，我把可测的数学留在纯函数里，剩下的在真实浏览器里验证。
这不是偷懒，而是一条诚实的边界：测确定性的东西，其余的在它真正运行的地方确认。
回报
加第五个工具时，我不需要回头重读前四个来确认没改坏。我跑 npm test。绿色就继续。这种不断累积的信心，才是全部意义所在。