过去我总觉得“测试是测试工程师的事，程序员不用管”，写代码时只做“简单跑一遍”的测试，只要能运行就提交。但读了《代码大全2》中“代码测试”的章节，才意识到：程序员自己写的代码，自己要先测好，测试不是“任务”，而是保证代码质量的“最后一道关卡”。
书中把程序员的测试分为“单元测试”和“集成测试”，其中“单元测试”让我收获最大——它要求针对每个函数、每个模块单独测试，验证其在各种情况下的表现（正常场景、异常场景、边界场景）。我之前写过一个“计算折扣”的函数，逻辑是“满100减20，满200减50”，只测试了“150元减20”“200元减50”这两个正常场景，就提交了代码。后来测试发现，当金额是“99元”（不满100）时，函数返回了负数；当金额是“300元”（满200）时，只减了20元。原来我写逻辑时漏了“不满100不减”的判断，还把“满200”的条件写错了。如果当初我按照书中的建议，写单元测试时覆盖“0元”“99元”“100元”“200元”“201元”这些场景，就能提前发现问题，不用等到测试阶段才返工。
书中还强调，测试要“尽早做”“反复做”。尽早做，是指写代码的同时就设计测试用例，而不是等全部代码写完再测试——比如写一个函数，就立即测试这个函数，有问题及时改；反复做，是指每次修改代码后，都要重新跑一遍测试，避免新修改引入旧bug。我曾在修改“用户登录”功能时，只测试了“正确密码登录”，没测试“错误密码”“空密码”“账号不存在”这些场景，结果上线后用户反馈“输错密码没提示”，不得不紧急修复。后来我养成了“写代码+写测试用例”同步进行的习惯，比如写“验证手机号”函数时，立刻列出“空手机号”“11位数字”“10位数字”“含字母的手机号”等测试用例，写完函数就逐一验证，大大减少了后续返工。
我还学会了书中的“错误猜测法”——根据经验猜测哪里容易出错，针对性设计测试用例。比如处理时间的函数，要测试“闰年2月29日”“1月1日”“12月31日”这些特殊日期；处理数字的函数，要测试“0”“负数”“最大值”“最小值”。有一次写“计算年龄”的函数，我特意测试了“出生年月日为0000-00-00”的异常场景，发现函数会抛出异常，提前修改了逻辑，避免了线上故障。《代码大全2》让我明白，测试不是“事后检查”，而是“提前防御”，程序员多花一点时间做测试，就能为后续节省大量排查和修复bug的时间。