引言
很多程序员都有这样的经历：花了两天时间写完一个模块，运行起来却处处报错，调试又花了两天。更糟糕的是，当终于让程序跑通后，却发现自己根本不确定它是否真的正确------边界情况处理了吗？异常输入会怎样？这种"先写后测"的开发模式，往往让我们陷入被动。
一个更聪明的做法是：在编写程序之前，先想好如何测试它。 这个看似简单的思维转变，能从根本上改变你的代码质量。
为什么"先想测试"如此重要
测试思维即设计思维
当你思考"如何测试这个函数"时，实际上你在回答几个关键的设计问题：
-
输入是什么？ 需要哪些参数，类型如何？
-
输出是什么？ 返回值、副作用分别是什么？
-
边界在哪里？ 空值、极值、异常情况如何处理？
-
职责是否单一？ 如果一个函数很难测试，通常意味着它承担了太多职责。
换句话说，可测试性差往往等同于设计差。一个难以测试的函数，通常也是耦合度高、职责不清的函数。
测试是需求的具象化
需求文档可能写着"用户登录功能"。但什么是登录成功？密码错误几次锁定？用户名大小写敏感吗？当你开始写测试用例时，这些模糊的需求被迫变得精确。测试用例本质上是用代码写成的、可执行的规格说明书。
实践方法：从测试用例到代码
假设我们要实现一个"计算购物车总价"的函数。不要急着写实现，先列出测试用例：
text
1. 空购物车 → 返回 0
2. 单件商品 → 返回该商品价格 × 数量
3. 多件商品 → 返回各商品小计之和
4. 商品数量为 0 → 该商品不计入
5. 商品价格为负 → 抛出异常
6. 应用折扣码 → 正确扣减
7. 折扣超过总价 → 总价不低于 0写这些用例时，你会发现很多设计问题：折扣码怎么传？异常用哪种类型？金额用浮点还是整数（分）？这些问题的答案，直接决定了你的接口设计。
然后再写实现，你会发现代码结构自然而然地清晰起来------因为测试用例已经帮你划定了每个函数的边界
三个层次的"测试先行"
1. 单元测试先行
对每个函数，先写出它的输入输出对。这是最基础的层次，适合核心算法和工具函数。
2. 接口测试先行
在设计模块间接口时，先写出调用方期望的代码。这能避免"实现完才发现接口不好用"的尴尬。
3. 验收测试先行
在开发功能前，先写出用户视角的验收场景。这确保你构建的是用户真正需要的东西。
常见的误区
误区一：测试先行等于 TDD。 不完全等同。TDD 强调严格的"红-绿-重构"循环，而"先想好如何测试"是一种更宽松的设计习惯------你不需要先写测试代码，但必须在脑中或纸上想清楚验证方式。
误区二：所有代码都要测试先行。 探索性原型、UI 布局调整等场景，先写后测更高效。关键是有意识地选择，而非默认先写实现。
误区三：测试写完就一劳永逸。 需求和设计会变，测试也要同步演进。测试是活文档，不是一次性产物。
收益：不只是少 Bug
坚持"先想测试"半年后，你会发现自己收获的远不止更少的 Bug：
-
调试时间大幅减少：问题在编写阶段就被发现；
-
重构更有底气：测试是安全网，敢改代码了；
-
沟通成本降低：测试用例是团队共享的精确语言；
-
设计能力提升：你开始本能地写出低耦合、高内聚的代码。
结语
"先想好如何测试"不是教条，而是一种对自己代码负责的态度。它强迫你在动手前思考清楚：我到底要做什么？怎么算做对了？这种思考，正是优秀程序员与普通程序员的分水岭。
下次打开编辑器前，不妨先问自己一句："这段代码，我打算怎么验证它是对的？" 答案清晰之时，便是编码开始之刻。