本篇主要是聊一聊以下几个方面的内容：

1. 为什么要单元测试
2. 单元测试框架
3. 单元测试的好处
4. 单元测试与重构

---

1. 为什么要单元测试

    我们购买的每一件产品，在出厂之前，一定是经历了各种质量检测，要尽量确保没有问题了才会进入市场的，作为客户，绝对是不想购买一件有问题的商品的。对于软件工程师而言，生产的产品就是所写的代码，在你交出自己的产品之前，你应该要确保自己的代码是满足需求而又质量可靠的。
    单元测试就是软件产品在代码层级的“质保书”。

2. 单元测试框架

    让我们把时钟拨到所有测试框架出现之前，你要如何确保设计的类的功能是满足预期的哪？类的功能是通过接口体现的，你也许会在每个类里单独写一个用于测试的main()，在它里面去调用类中所有的public方法，依次去判断这些方法的输入/输出是否符合预期。你也许会为需要测试的每一个类建立一个独立的、与之相匹配的测试类，在这个单独的测试类里写一个main()，去依次检测待测试类的public方法。无论采用哪种方法，想要正交并自动地测试待测试类的public方法都是难以实现的。
    单元测试若不能快速地完成，也便失去了存在的价值，自动化的需求是必须且迫切的。Java开发者是幸福的，Kent Beck和Erich Gamma在万米高空的飞机上结对编程，构建了大名鼎鼎的JUnit单元测试框架。金风玉露一相逢，便胜却人间无数，JUnit不仅满足了Java开发者对自动化测试的需求，也将Java带入了测试驱动开发的新时代，更催生了各种各样的测试框架的出现。
    因此，对于开发者而言，寻找与你使用的开发平台相关的单元测试框架，搭建起来，慢慢体验尝试吧。

3. 单元测试的好处

    只要有过一年半载开发经验的人就知道，编写代码只占很少一部分工作时间，更多的时间是花在了代码的维护上。提到维护，自然避不开令人讨厌的各种各样的bug，对于bug，找到并复现bug所花的时间又远远大于修改它的时间。一套测试就是一个强大的bug侦探器，它能够大大缩减查找bug所需要的时间。
    再者，单元测试代码又相当于待测试代码的客户，通过编写单元测试，你会发现你对代码的理解会越来越深。最重要的是，对测试代码而言，它关注的是接口的功能本身，而非接口具体是如何实现的，这种视角的转变是面向对象思考的核心所在，是设计灵活、可复用、易维护代码的基础。
    最后，单元测试可以促使你编写容易测试的代码，会将代码自然而然地引向依赖注入和分层的设计结构上去。

4. 单元测试与重构

    重构是需要有测试做保证的。重构需要小步快进地修改代码，对于每一次修改，需要确保代码修改前后的功能是不变的。回顾一下重构的定义：

重构（名词定义）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词定义）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

    因此，没有单元测试，就无法确保调整前后，软件的可观察行为是否发生了改变，这等同于在没有保险带的情况下高空走钢丝。

理想是丰满的，现实是骨感的，对于国内的公司有多少有做单元测试的没有做过调查统计，但从个人了解到的情况看并不乐观，好在有强大的IDE工具，使用IDE工具提供的Refactor功能，还是可以谨慎地做些重构的。但最好还是尝试做一些单元测试，哪怕测试覆盖率很低，也是极有好处的。