为什么使用单元测试-JavaEE编程技术

我们编写代码时，一定会反复调试，以保证它能够编译通过。对于编译没有通过的代码，没有人会愿意交付给自己的项目经理。但代码通过编译，只是说明它的语法正确，却无法保证它的语义也一定正确，没有人可以轻易承诺这段代码的行为一定是正确的。单元测试则可以为我们的承诺做保证，编写单元测试就是用来验证这段代码的行为是否与期望的一致。有了单元测试，可以自信地交付自己的代码，而没有任何后顾之忧。

什么时候测试？单元测试越早越好，按极限编程的理论，是测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从实践来看，先编写产品方法的框架，然后编写测试方法，针对产品方法的功能编写测试用例，然后编写产品方法的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品方法的框架，是指框架中先编写空的方法体，有返回值的随便返回一个值，编译通过后，再编写测试代码，这时，方法名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，包含了单元测试的代码才是已完整的代码，提交产品代码时也要同时提交测试代码。测试部门可以做一定程度的审核。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在Java这样的面向对象的语言中，要进行测试的基本单元是类。单元测试的原则同样被扩展到第四代语言（4GL）的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。(www.xing528.com)

单元测试作为一种无错误编码的辅助手段，无论是在软件修改还是在代码移植过程中，都必须是可重复的，软件测试贯穿在整个软件系统的运行、维护、升级、扩展等阶段。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review）、静态分析（Static analysis）和动态分析（Dynamic analysis）。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪、时间分析，以及测试覆盖度方面的信息。

经验表明，一个尽责的单元测试方法将会在软件开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。在软件开发的后期阶段，Bug的发现并修改将会变得更加困难，并要消耗大量的时间和开发费用。无论什么时候做出修改，都要进行完整的回归测试，在生命周期中尽早地对软件产品进行测试将使效率和质量得到最好的保证。在提供了经过测试的单元的情况下，系统集成过程将会大大地简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不是陷入充满很多Bug的单元之中不能自拔。