你有没有过这种经验：
- 刚修完一个 bug，测完了，觉得很棒；结果才过几天就又收到新的 bug 回报，原本修好的功能好像又坏了。
- 每次调整了一点程式逻辑，就得在浏览器上点来点去，测完后才发现上次修的另一个地方又被影响了。
- 感觉自己整天都在处理突发状况、火烧屁股的事情，一天下来忙到翻，但却说不出忙在哪里。
如果你也有这些感受，那可能是因为「还没开始单元测试的你一定很忙」。当我们没有任何自动化测试时，开发过程中看似省事，但却常常在后期付出更多的时间成本。这篇文章要和你分享：其实一个人就能开始单元测试，并透过一些简单的测试，替自己「减轻」开发的负担。
这么做对我有什么好处？
不用再手动一个一个按
没写测试时，每次修改功能后，你可能就要打开浏览器，进行多种操作流程、点击不同按钮，直到确定「好像没坏」才放心。但只要你建立了一两个「简单的自动化测试」，每次改完程式就能跑一下测试，程式会自动帮你做检查，比手动测好多了。
某次上线前，不小心改错了某个Function导致计算结果都不正确，手动测试很难一下子发现。但有测试后，一跑测试就立刻红灯警告，避免了正式上线的灾难。
随时知道程式哪里坏掉
有测试时，只要程式的某部分坏了，跑测试就能快速告诉你问题在哪里，甚至在哪个函式或哪段程式码。少了手动排查流程，也更能快速锁定问题。
给自己多一层保护
测试不只是给大公司或大团队用的保护网，就算是自由工作者、Side Project 开发者，或是团队里最孤独的我，也能靠「几条测试」降低反覆 Debug、修 Bug 的风险。
为什么大多数人还没开始测试？
「感觉很难，不知道从哪开始」
大部分初学者对测试的印象是「要写很多莫名其妙的函数，而且一开始就要很复杂」。事实上，测试也可以很简单，从最容易的函式测试下手就行。
「时间不够、进度太赶」
很多人认为写测试会拖慢开发速度，「老闆都在催了，哪有时间写测试？」然而，你现在没花的测试时间，往往会在未来的 Debug 与重构中「双倍奉还」。
「没看到好处，觉得测试只是浪费时间」
有些人没亲身体验过测试带来的效率提升，所以觉得只是不必要的额外工。对此，我们可以透过小规模的实验、局部的测试来累积信心。
上面提到的只是常见阻力，并不代表所有人都如此。有些开发者早就把测试当成日常，也有团队在某些专案中推行，但在其他专案却没时间做。每个环境都不一样，需要具体情境来思考。
行动吧：一个人也能做什么？
- 想想看，你最常被报 bug 的功能是什么？最常因一点小改动就坏掉的 module 又是哪个？先从这里下手写测试。
- 举例：一个常常要计算折扣的函式，或是一个复杂的字串处理逻辑。先写几条简单的测试用例，确保输入 A 就一定回传 B。
- 单元测试英文叫作「Unit Test」，就是聚焦在「Unit」级别的小单位测试。
- 如果你的程式码是一整块，可以尝试把它抽出来成为独立函式，再对这个函式写测试。
- 别想太复杂，只需要：
- 安装 PHPUnit（或任何你想用的测试框架），
- 新增一个测试档，
- 里面写一个 testXxx() 方法，测试你想测的函式。
- 在自己的专案里面，主动记录一下：自从你多写了几条测试后，是否在之后的改动中更快发现错误？或是手动测试的次数减少了？
- 这样的「证有」证明会是你在团队或老闆面前宣传测试时的好材料。
「还没开始单元测试的你一定很忙」，不是一句随便的口号，而是无数过来人累积下来的经验谈。
- 单元测试带来的好处，不需要等到团队一起行动才看得到；只要你愿意花一点时间尝试，就能在日常开发中感受到有测试的踏实感。
- 当然，仅仅靠一两个测试档，还不能代表已经完整覆盖所有情境，但它至少能「证明」测试在某些情境下确实有效。
下一篇，我们一起正式进入 PHPUnit 的世界，教你如何安装与撰写第一个简单的测试。只要做完下一篇，你就能从「不知道测试是什么」进阶到「写出你的第一支测试」，帮助你一步一步往更完善的测试之路迈进。
文章回顾：
希望你能在看完本文之后，尝试写下你的第一只测试，让自己不再「忙到翻」而是「忙得有条不紊」！
如果你想知道如何安装与使用 PHPUnit，欢迎 走进 PHPUnit 的世界：从 0 到 1 的测试入门！
更多实用开发技巧在：詹姆士的软件易开罐