3.2 单元测试的重要性

激烈的商业竞争、飞速发展的新兴技术使得企业需要比以往更快速地交付高质量的软件。因为项目工期紧，任务重，很多开发人员会把主要时间用在编写业务逻辑代码上，有时间的时候才会写一些简单的单元测试代码，甚至不写单元测试。理由如下：

• 没时间写单元测试。

• 单元测试并不能防止漏洞的出现。

• 这段代码很简单，为什么还要写单元测试？

其实，不写单元测试的根本原因还是很多开发人员不了解单元测试所能带来的好处，所以才会认为写单元测试是浪费时间，不去写单元测试。

这里引用J.Timothy King“关于单元测试的十二个好处”。

1）单元测试可以证明你的代码真能解决问题

这意味着缺陷减少。单元测试当然不能取代系统测试和验收测试，但能补足它们的短处。

2）可以获得一组底层回归测试

开发人员可以随时检查程序不工作的部分和发现缺陷所在位置。很多团队会每天运行整组单元测试，这样可以在交付程序给质管部门之前及早发现缺陷。

3）可以在不破坏现有功能的基础上持续改进设计

一旦有了单元测试，开发人员就可以很方便地重构代码。只要在重构以后重新运行单元测试就可以知道是不是破坏了现有功能。

4）边写单元测试边写代码是更有趣的工作方式

通过编写单元测试，开发人员能更好地理解代码需要实现的功能。在实际系统没有完成的情况下，可以通过单元测试运行编写的代码。代码的成功运行会给开发人员带来成就感，激励他们去完成后面更多的工作。

5）可以真实地反映开发进度

因为代码可以在实际系统没有完成的情况下运行（在单元测试的帮助下），所以开发人员可以随时展示他们的进度。而且，因为有单元测试，所谓的“编码完成”不仅仅是写完代码，签入代码库，还能够无缺陷地运行。

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

我们都碰到过那种不知道该怎么用的函数或类，这种情况下一般会先去找范例代码，但是通常内部使用的代码不会有范例。幸运的是单元测试可以作为一种文档，当不知道某个函数怎么使用时，看一下单元测试代码怎么写即可。

7）促使写代码前先做规划

先写测试（后写代码）会促使开发人员在动手开发前把必须完成的事和整体设计考虑一遍。这不但会让他们更专注，还能让设计更漂亮。（本章后面会介绍测试驱动开发的相关内容）

8）降低缺陷修复成本

缺陷发现得越早越容易修复。发现得晚的缺陷通常是好几处代码变动引发的结果，而且往往不知道究竟是由哪个变动造成的，这使得修复缺陷变得相当困难。单元测试能帮助开发人员及早发现缺陷。

9）单元测试甚至比代码审查的效果还要好

有人说事前代码审查比事后测试更好，因为发现和修复缺陷的成本更低。如果代码发布后才去修复缺陷，成本就高得多。而单元测试能够比代码审查更早地发现缺陷。

10）无形中为开发人员消除了工作上的障碍

开发人员在编码时可能会碰到无法继续工作的障碍。单元测试能够系统化代码结构，帮助开发人员将注意力集中到创造新功能上。他们可能卡在不知道如何测试下一段代码，或者不知道如何让测试通过，但他们永远知道下一步该做什么。有时候你很想在累倒之前休息一下，但是因为工作进行得很顺，使得你根本不想停下来。

11）单元测试促成更好的设计

为了测试一段代码，开发人员需要清晰地定义代码的功能。如果代码测起来很简单，这表示这段代码功能清晰，具有很高的聚合度。如果代码能通过单元测试，说明它很容易被整合到实际系统中，和周边代码具有松耦合的依赖关系。高内聚和松耦合往往是优秀设计的标志。同时容易通过单元测试的代码也容易维护。

12）编写单元测试会使开发效率更高

编写单元测试会使开发效率更高。换句话说，忽略单元测试也许能更快完成编码，但是无法保证代码能真正工作，以后开发人员可能不得不花费大量精力去修复代码缺陷。而单元测试能够从源头发现问题，快速修复缺陷。

综上所述，单元测试很重要，和写功能代码一样重要。