「写单元测试的好处是什么?」

「只有写了才知道」

1. 单元测试保证你的code真的能动

这会让bug减少。当然，单元测试不能取代系统测试和验收测试。但单元测试能补足他们的短处。

2. 你会得到一组低层的regression-test suite

这让你随时可以回头去检查有否哪些坏掉、bug在哪。很多团队会每天把整组测试跑一遍。这让你在把程序交给品管部门之前，可以很轻松的把bug抓出来。

3. 让你改善系统设计的时候，不怕弄坏系统

其实就是测试先行3步骤的第3步。通常测试先行写出来的code不太需要重构。我看过很多超糟糕的系统，就像精神病患一样，根本无法搞定。如果有准备好单元测试，你就可以对系统里面最难搞的部份做出有效的重构。

4. 写测试会让coding更好玩

你会先搞懂自己的code要做什么。然后再让它完成任务。就算系统还没全做完，你还是能看到code真的动起来，而且真的没出错。你会得到一种「我完成了!」的感觉。每分钟都会不断感受到喔。只要试试测试先行，你就会整个人high起来、对自己的作品感到骄傲、被激励去完成更多事情。

5. 它们可靠地展现目前进度

你不用为了等整个系统组装起来而多等一个月。在系统完成之前你就能展示进度了。不但能说自己写了code，还能真的跑给别人看。传统开发有件事搞错了。「完成」不等于你写了code然后丢出去。「完成」应该是你的code能在系统裡跑，而且没bug。写测试会让你更接近这点。

6. 单元测试是一种使用范例

我们都碰过那种不知道怎么用的library。通常我们会先去找範例程式码。使用範例可算是一种文件。但公司内部的code通常不会有範例可看。所以只好慢慢试、在系统内东找西找了。因为那个同事可能根本离职了，想问他都没办法。单元测试可以当作一种文件。当你不知道Foo类别怎么用，去看一下单元测试怎么写的即可。

7. 测试先行会强迫你写code前先做规划

先写测试会逼你在动手开发前把必须完成的事和整体设计想过一遍。不但让你更专注，还能让设计更漂亮。

8. 先写测试能减少bug的成本

越早发现bug越容易修。之后出现的bug通常是改了好几个地方才出现的，

导致很难抓出哪裡导致了bug。一开始先找出bug在哪，然后要重新回想这段code是怎么写的，因为可能是几个月前写的。最后才终于弄懂，搞出一套解法。只要能减少抓bug以及修好bug的时间，几乎都算大赚。如果在成品交给品管部门或是顾客之前，我们只花几天就找出bug，通常算是很幸运。那几花几分鐘就找出bug呢?测试先行就能做到这点。

9. 它比代码检查的效果好

有人说事前代码检查比事后测试系统更好，因为成本比较低。在系统完成之后才测试系统，要修好bug可说是麻烦多了。越早发现bug，就越简单、越便宜、越好搞定。代码检查的好处就在这：只花几天就能抓出bug，不需要等几个月。但是测试先行成本更低。只要几分鐘就抓出bug，连几天都不用。

10. 几乎解决了「开发者瓶颈」(coder’s block)

不知道下一行写什么吗?就跟「作家瓶颈」(writer’s block)一样，开发者瓶颈很可能是个大问题。测试先行有系统地处理开发上关于结构的部份，让你能专心在需要创造的部份。你可能会卡在下段code不知道怎么测、该怎么通过测试，但你永远不会因为下一步卡住。通常会有完全相反的结果：你很想在累倒之前休息一下，但因为清楚看到前面的录了，所以根本不想停下来。

11. 单元测试让设计更棒

测试一小块code会强迫你定义清楚那段code负责什么。如果测起来很简单，就表示它的责任很明确，cohesion很高。如果一段code能被单元测试，那就表示它很容易就能放进系统之中，就跟它很容易放进测试之中一样。它跟相关的code只具有loose coupling 。 High cohesion与loose coupling代表了出色、好维护的设计。容易测试的code也很容易维护。

12. 写测试会让开发速度更快

不写单元测试也许会让速度更快，但无法保证code真的能跑。开发上会花一堆时间在在事后的修bug。测试先行会消除这类的浪费，从一开始就做对、让bug更好修。

就算好处这么多，很多工程师还是继续维持他们的老样子。如果你在组织里极度重视流程，你跟他们一部份人会起衝突。我只能祝你好运。记住一件事，人们不会因为一个东西听起来不错就买帐。他们只有在极度渴望、超想得到手来品嚐时才会买帐。希望以上几点可以帮助你说服他们。