Java开发工具集之单元测试工具
使用JUnit、AssertJ和Mockito编写单元测试和实践TDD
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.（如果建筑业者用程序员写程序的方式盖楼造桥，那么第一只飞来驻足的啄木鸟就足以毁灭人类文明）
—Weinberg's second law（温伯格第二定律）
当前我国的软件行业普遍缺乏专业性
杰拉尔德·温伯格（Gerald M. Weinberg）是软件开发行业的老前辈，有史以来最伟大的程序员之一。如果说Martin Fowler、Kent Beck、Robert C. Martin等人是我们行业的贤人，温伯格就是行业的哲人。他是杰出的程序员、专业作家和思想家，著有30多本书籍和数以百计的论文，我有幸读过其中的几本，包括《你的灯亮着吗？》、《咨询的奥秘》、《理解专业程序员》、《成为技术领导者》、《程序开发心理学》和《系统化思维导论》等。其中《你的灯亮着吗？》最为家喻户晓，而《系统化思维导论》最启迪智慧（个人观点，不喜勿喷）。
温伯格上面这段话引起我心中强烈的共鸣。笔者在软件开发行业中摸爬滚打，至今也有二十来年了。这么多年以来，最强烈的感觉就是：我们行业中绝大多数的开发者、组织和产品，都严重缺乏专业性。既缺乏专业能力，更缺乏专业意识。我们的产品内部质量堪忧，而且自动化测试覆盖远远不足。与会计、建筑、医学等行业相比，软件开发的专业性现状还差的远。温伯格在《理解专业程序员》一书中说过，在欧洲，一个侍者可能要经过10年，甚至20年的训练，才能获准在一个一流饭馆服务。而我们的程序员只要有5年的工作经验，就敢号称行业专家了。
专业性从编写单元测试开始
要成为专业程序员，请从编写单元测试开始。通过单元测试，证明你写的每一个类的每一个有意义的公开方法在各种正常和异常的条件下都遵守它的API契约，符合你的设计意图，从软件最底层的实现代码开始证明你写的程序的正确性和可靠性。毕竟，如果你都不能证明底层代码的正确性和可靠性，又怎敢觍颜声称自己是“专业程序员”？
TDD：先写好单元测试，再写实现代码通过测试
是否采用测试驱动开发（简称TDD），是专业程序员与业余程序员的分水岭。
TDD是多个敏捷方法论力推的最佳实践之一。如果只能保留一个敏捷最佳实践，我必然是保留TDD。如果可以保留两个，那就再加上持续集成。
采用与不采用TDD，代码质量和设计质量有天壤之别。
不采用TDD的，也有写的好的代码（但很罕见）。采用TDD的，基本都是好代码。长期坚持TDD，程序员的的代码和设计会越来越好。你会感觉写代码越来越像写诗，而不是像搬砖；你自己成了诗人，而不再是悲催的码农。你不再需要加班加点寻找和改正Bug；你不再需要担心在一个地方修改代码会导致在意想不到的地方冒出新的几个Bug，即使有，你也可以及时发现、准确定位Bug并加以改正；你晚上会睡得比较安稳，不用担心领导或客户半夜的夺命连环call；你对自我形象感觉满意，因为在同事、领导和客户面前书里了专业、可靠的形象。
单元测试工具集：JUnit、AssertJ和Mockito
JUnit、AssertJ和Mockito是单元测试三剑客。JUnit用于编写和执行测试，AssertJ用于编写断言，而Mockito用于编写测试替身，以隔离被测类的协作者，使得测试范围真正局限于代码“单元”，而不至于变成集成测试。
本教程将讲述如何利用这三大工具编写单元测试和进行测试驱动开发。我力图达到以下的目标：
- 遵循80/20原则，重点剖析三大工具中最重要、最常用的功能。
- 系统。不是散漫地介绍一个个知识点，而是以“知识树”的方式去讲述。
- 简单。不讲废话。直接以代码方式呈现测试范例。我深信一千克纯金比十吨金矿石更有价值。
- 直接。所有的东西尽可能以列清单一二三四的方式指导学员去实现。
现在，让我们一起迈出成为专业程序员的第一步，从单元测试和TDD开始。