1. 为什么要单元测试

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

2. 单元测试框架

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

3. 单元测试的好处

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