单元测试（一） 概述

ganglia 开发结束，然后开始补单元测试
(虽然搞了半年devops，知道要TDD，要UT，要CI ，BTW 实际上能干完活就不错了。谁管这些)

what

单元测试(unit testing)，是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。

why

优点

1.帮助开发人员编写代码，提升质量、减少bug。
编写单元测试代码的过程就是促使开发人员思考工作代码实现内容和逻辑的过程，之后实现工作代码的时候，开发人员思路会更清晰，实现代码的质量也会有相应的提升。
2.提升反馈速度，减少重复工作，提高开发效率。
开发人员实现某个功能或者修补了某个bug，如果有相应的单元测试支持的话，开发人员可以马上通过运行单元测试来验证之前完成的代码是否正确，而不需要反复通过发布war包、启动jboss、通过浏览器输入数据等繁琐的步骤来验证所完成的功能。
3.保证你最后的代码修改不会破坏之前代码的功能。
项目越做越大，代码越来越多，特别涉及到一些公用接口之类的代码或是底层的基础库，谁也不敢保证这次修改的代码不会破坏之前的功能，所以与此相关的需求会被搁置或推迟，由于不敢改进代码，代码也变得越来越难以维护，质量也越来越差。而单元测试就是解决这种问题的很好方法。
4.让代码维护更容易。由于给代码写很多单元测试，相当于给代码加上了规格说明书，开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。
很有opensource的项目都有相当量的单元测试代码，通过读这些测试代码会有助于理解生产源代码。
5.有助于改进代码质量和设计。除了那些大拿们编写的代码，我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。
虽然说单元测试本身不能直接改进生产代码的质量，但它为生产代码提供了“安全网”，让开发人员可以勇敢地改进代码，从而让代码的clean和beautiful不再是梦想。

缺点

1.单元测试的学习成本比较高。编写单元测试涉及的技术很多，如果只是单纯的使用Junit或是TestNG这样的基础单元测试框架往往很难应对各种复杂的单元测试情况，所以势必要借助很多第三方的框架和技术(easymock，jmock，dbunit等等)，这些框架和技术的学习还是会增加学习的成本和难度。
2.编写单元测试会增加程序员工作量。单元测试跟生产代码是一样的，并不会应为是用来测试的就有所不同，开发人员同样要面对测试代码的编写、维护等工作，也同样要面对避免重复代码等一系列问题，能否写出好的测试代码还是取决于开发人员的设计和编码能力。
3.推广和运用单元测试需要比较大的投入。只有在每个开发人员都编写了足够的、质量好的单元测试代码，大家才能真正享受到单元测试带给我们的好处。在达到这种层度以前，还需要不少实现和资源的投入。总结虽然单元测试也有一些缺点和负面的效应，但跟单元测试的优点比较起来，为了克服和解决这些缺点所在的付出是值得的。

how

Java使用 JUnit(推荐使用JUnit4)
maven 使用corbertura 插件
mock使用 jmockit 等