测试是大型开发过程中基本原则的在任何职业中验证都是个重要部分医生要通过验血来确诊波音公司在研制 777 过程中对飞机每个组件都进行了精心测试为什么软件Software开发就应该例外呢？

　　以前由于在应用中将 GUI 和商业逻辑紧密联系在起这就限制了创建自动测试能力当我们学会通过抽象层将商业逻辑从界面中分离出来时各个单独代码模块自动测试就替代了通过 GUI 进行手工测试

　　现在集成开发环境 (IDE) 能在您输入代码同时显示对于在类中快速查找思路方法具有智能探测功能可以利用语法结构生成彩色代码而且具有许多其它功能因此在编译更改过代码的前您已经全盘考虑了将构建类但您是否考虑过这样修改会破坏某些功能呢？

　　每个开发者都碰到过更改“臭虫”代码修改过程可能会引入“臭虫”而如果通过用户界面手工测试代码话在编译完成的前是不会发现它然后您就要花费几天时间追踪由更改所引起最近在我做个项目中当我把后端数据库由 Informix 更改到 Oracle 时就遇到了这种情况大部分更改都十分顺利但由于数据库层或使用数据库层系统缺少单元测试从而导致将大量时间花费在尝试解决更改“臭虫”上我花了两天时间查到别人代码中个数据库语法更改(当然那个人仍是我朋友)

　　尽管测试有许多好处但般员对测试都不太感兴趣开始时我也没有您听到过多少次“它编译了所以它定能用”这种言论？但“我思故我在”这种原则并 不适用于高质量软件Software要鼓励员测试他们代码过程必须简单无痛

　　本文从某人学习用 Java 语言编程时所写个简单类开始然后我会告诉您我是如何为这个类编写单元测试以及在编写完它以后又是如何将单元测试添加到构建过程中最后我们将看到将“臭虫”引入代码时发生情况

　　从个典型类开始

　　第个典型 Java 般都包含个打印 "Hello World" 在清单 1 中我创建了个 HelloWorld 对象例子并 sayHello 思路方法该思路方法会打印这句习惯说法

　　清单 1. 我第个 Java 应用 "Hello world"

/*
*　HelloWorld.java
*　My first java program
*/
HelloWorld {
　　/**
　　 * Pr "Hello World"
　　 */
　　void sayHello {
　　　　　.out.prln("Hello World");
　　　}
　　/**
　　 * Test
　　 */
　　public void ( String args ) {
　　　　HelloWorld world = HelloWorld;
　　　　world.sayHello;
　　}
}

　　 思路方法是我测试哦噢！我将代码、文档、测试和样本代码包含在了个模块中保佑 Java！但随着越变越大这种开发思路方法很快就开始显现出了缺陷:

　　混乱

　　类接口越大 就越大类可能仅仅正常测试而变得非常庞大

　　代码膨胀

　　由于加入了测试所以产品代码比所需要要大但我不想交付测试而只想交付产品

　　测试不可靠

　　既然 是代码部分 就对其他开发者通过类接口无法访问私有成员和思路方法享有访问权出于这个原因这种测试思路方法很容易出错

　　很难自动测试

　　要进行自动测试我仍然必须创建另来将参数传递给

　　类开发

　　对我来说类开发是从编写 思路方法开始我在编写 时候就定义类和类使用方法然后实现接口它些明显缺陷也开始显现出来个缺陷是我传递给 来执行测试参数个数其次 本身在进行子思路方法、设置代码等操作时变得很混乱有时 会比类实现其余部分还要大

　　更简单过程

　　我原来做法有些很明显缺陷因此让我们看看有什么别思路方法可以使问题简化我仍然通过接口设计代码并给出应用举例正如原来 样区别是我将代码放到了另个单独类中而这个类恰好是我“单元测试”这种技术有以下几点好处:

　　设计类种机制

　　是通过接口进行开发所以不太可能利用类内部功能但我是目标类开发者我有到其内部工作“窗口”所以测试并不是个真正黑箱仅凭这点就足够推断出需要开发者本人在编写目标类同时负责测试开发而不是由其他任何人代劳

　　类使用方法举例

　　通过将举例从实现中分离出来开发者可以更快地提高速度而且再不用在源代码上纠缠不清这种分离还有助于防止开发者利用类内部功能这些功能将来可能已经不存在了

　　没有类混乱

　　我不再受到 限制了以前我得将多个参数传递给 来测试区别配置现在我可以创建许多单独测试类每个都维护各自设置代码

　　接下来我们将这个单独单元测试对象放入构建过程中这样我们就可以提供自动确认过程思路方法

　　确保所做任何更改都不会对其他人产生不利影响

　　我们在进行源码控制的前就可以测试代码而无需等待汇编测试或在夜晚进行构建测试这有助于尽早捕捉到“臭虫”从而降低产生高质量代码成本

　　通过提供增量测试过程我们提供了更好实现过程如同 IDE 帮助我们在输入时捕捉到语法或编译“臭虫”样增量单元测试也帮助我们在构建时捕捉到代码更改“臭虫”

　　使用 JUnit 自动化单元测试

　　要使测试自动化您需要个测试框架您可以自己开发或购买也可以使用某些开放源代码工具例如 JUnit我选择 JUnit 出于以下几个原因:

　　不需要编写自己框架

　　它是开放源代码因此不需要购买框架

　　开放源代码社区中其他开发者会使用它因此可以找到许多举例

　　它可以让我将测试代码和产品代码分开

　　它易于集成到我构建过程中

　　测试布局

　　图 1 显示了使用样本 TestSuite JUnit TestSuite 布局每个测试都由若干单独测试案例构成每个测试案例都是个单独类它扩展了 TestClass 类并包含了我测试代码即那些曾在 中出现代码在该例中我向 TestSuite 添加了两个测试:个是 SkeletonTest我将它用作所有新类和 HelloWorld 类起点

　　图 1. TestSuite 布局

　　public String sayHello {
　　　　 HELLO_WORLD;
　　}
}

　　在构建包时我们看到了清单 7 显示了 runtest 中它显示了失败测试类和测试思路方法并介绍说明了为什么会失败我们返回到代码中改正后离开

　　清单 7. 构建举例

E:projectssample>ant runtests
Searching for build.xml ...
Buildfile: E:projectssamplebuild.xml
JUNIT:
compile:
jar:
compiletests:
runtests:
　　[junit] ..F
　　[junit] Time: 0
　　[junit]
　　[junit] FAILURES!!!
　　[junit] Test Results:
　　[junit] Run: 2 Failures: 1 Errors: 0
　　[junit] There was 1 failure:
　　[junit] 1) testSayHello(test.com.company.HelloWorldTest) "expected:<Hello
　　　　　　　 World> but was:<Hell0 World>"
　　[junit]
BUILD FAILED
E:projectssamplebuild.xml:35: Java ed: -1
Total time: 0 seconds



　　并非完全无痛

　　新过程并不是完全无痛为使单元测试成为开发部分您必须采取以下几个步骤:

　　下载和安装 JUnit

　　下载和安装 Ant

　　为构建创建单独结构

　　实现和主类分开测试类

　　学习 Ant 构建过程

　　但好处远远超过了痛苦通过使单元测试成为开发过程部分您可以:

　　自动验证以捕捉更改“臭虫”

　　从接口角度设计类

　　提供干净举例

　　在发行包中避免代码混乱和类膨胀

　　实现 24x7

　　保证产品质量要花费很多钱但如果质量有缺陷花费钱就更多如何才能使所花钱获得最大价值来保证产品质量呢？

　　评审设计和代码 评审可以达到效果是单纯测试半

　　通过单元测试来确认模块可以使用 尽管测试早就存在但随着开发实战不断发展单元测试逐渐成为日常开发过程个部分

　　在我 10 年开发生涯里为 emageon.com 工作是最重要部分的在 emageon.com 时设计评审、代码评审和单元测试是每天都要做事这种日常开发习惯造就了最高质量产品软件Software在客户地点第年当机次数为零是个真正 24x7 产品单元测试就象刷牙:您不定要做但如果做了生活质量就更好