T
tuti
Unregistered / Unconfirmed
GUEST, unregistred user!
前一阶段，为在公司内部推广junit使用写的一篇稿件。
Jbuilder 集成了junit后使用很便捷，但对从没使用过
的人来说毕竟还是有些门槛。
原文是word格式，不知道怎么在“大富翁”上发布。
只能另存为txt格式。图片、DEMO都无法上传，排版也不好。
但本着“重在搀乎”的原则，还是发布一个txt版本。
=================================================
JUnit 使用介绍
作者： tuti tut@citiz.net
关键字：单元测试， 框架 ，JUnit
版本 1.0
JUnit 使用介绍 1
什么是单元测试(Unit Test) 1
常见的工作场景 2
场景1： 2
场景2： 2
场景3： 2
Java程序的传统测试方法： 3
Main测试法弊端： 3
理想中的单元测试的一些特征： 3
JUnit 使用介绍 3
测试框架 3
JUnit介绍 3
JUnit结构 4
Jbuilder7中Junit使用 5
Junit若干实践问题 8
JUnit实施 9
实施路线 9
不适用的范围 9
成功案例 10
结束语 10
参考资源 10
我们所要做的一切是尽可能快地犯错误。
——约翰.阿奇博尔德.惠勒
什么是单元测试(Unit Test)
程序设计领域中有很多种测试，单元测试只是其中的一种。
测试只能找到程序中的部分错误，难以保证程序完全正确无误。
单元测试定义：单元测试是在软件开发过程中，要进行的最低级别的测试活动，
在单元测试活动中，软件的独立将在与程序的其他部分相隔离的情况下进行测试。
完成单元测试是开发人员的日常工作，它是由程序员自己进行的测试工作。
单元测试所测试的是“程序代码单元是否按照预设的方式执行而产生的合乎期待的结果”，也就是程序代码的正确性。
单元测试的必要性：还有必要讨论吗？
常见的工作场景
场景1：
甲： 你那个“解析表达式”模块完成了怎么样?
乙： 代码已经完成了，但还没测试，我现在很忙，等我把剩下的模块全部完成了再来测试。
甲： 那当你完成了 90%。 心想：“但愿如此。。。”（悬！）
分析：
1． 单元测试实现起来需要简单方便，否则没人愿意做完整测试。
2． 没有测试的进度估算，失真的可能性很大。
场景2：
甲： 我需要使用你的那个“解析表达式”的模块。你的模块测试了吗？
乙： 测试过了。
甲： 都测试了哪些情况？
乙： 除了没测试的，都测试过了。
甲：(晕!) 那测试文档有吗？
乙： 很忙，没时间写。
甲： （再晕！）
分析：
1． 对于接口程序，需要能完整的描述接口的行为。
2． 需要可读性良好的资料，使与该程序的相关各方面，能进行良好的沟通。
场景3：
乙： 那个“解析表达式”的模块，效率太低，写得又乱，我想重写一下。
甲： 现在起码还能用，快交货了，你就老实点吧，别又搞出点BUG来。
乙： （郁闷!）
分析：
1． 在没有完整的测试安全网的情况下，对代码进行修改的风险很大。
Java程序的传统测试方法：
就一般java程序而言，程序员大多利用的在相应需要测试的类中添加main函数。
在main函数中，建立对象实例，调用需要测试的方法并打印结果。程序员通过打
印出来的结果，来判断执行是否准确。
Main测试法弊端：
1． 在需要交货的程序中，混杂有多余的代码。
2． 很难进行多了个类的集成测试。
3． 过多的打印语句不利于判断测试结果。
4． 逐个执行每个类的main方法，工作量很大。
理想中的单元测试的一些特征：
1． 完成一个测试，只需要少量测试代码。
2． 多个测试可以集成，进行回归测试。
3． 测试代码，和被测试代码完全分离。
4． 测试的自动化、快速，测试结果一目了然。
5． 测试代码有良好的可读性，具备文档作用，便于各方沟通。
JUnit 使用介绍
测试框架
为了达到以上理想中的单元测试，单个类或对象很难达到目的，而需要使用单元测试框架。
框架（framework）是指构成一组特定软件可复用设计的一组相互协作的类。
框架规定了你的应用的体系结构。它定义了整体结构，类和对象的分割，各部分的主要
责任类和对象是怎么协作，以及控制流程。框架预定意义了这些设计参数，以便于应用
设计者或实现者能集中精力于应用本身的细节。
JUnit介绍
目前在Java开发社区中，JUnit是最为流行的测试框架。而且Junit是开放源代码的，不需要购买。
打开JUnit的官方网站http://www.junit.org 是这样来介绍Junit“JUnit是由Erich Gamma、
Kent Beck所写的用于回归测试的框架”。 而Erich Gamma是《Design Partterns》的主要作者，
Kent Beck是“Extrme Programming”运动的主要旗手。
都是软件开发领域的重量级人物。（XP的简介见 参考资源4）
JUnit结构
Junit 提供了junit.framework.TestCase ， junit.framework.TestSuite基础类用来编写单元测试。
提供3个运行器(runnners), TestUI, SwingUI, AwtUI,来查看测试结果。TestCase和TestSuite都实现
了Test接口。不同之处在于，TestCase用以容纳一个个独立的Test方法,test suite用以将一系列相关的
test cases编成一个组。一个test Suite 可以容纳 若干个 test case和test suite。TestCase 可以
进行针对一个类的单元测试。TestSuite对TestCase进行了编组以后就可以对多个类进行回归测试。
Junit使用 断言（Assert）语句来进行结果的真伪判断。类似MFC中的ASSERT宏。
断言语句在junit.framework.Assert包中，例如：
assertEquals() 判断是否对象是否相等。
assertTrue() 判断boolean型的真伪。
assertNotNull() 判断对象是否不为空。
建立一个新的单元测试时，需建立一个TestCase的子类，在类中添加自定义的测试方法。测试方法名需要以 test来头，
如testSum( )。一个testXXX的测试方法，必须是 public方法，无返回值，无参数。在测试方法中，使用的适当的
断言语句，即完成了一个测试方法。
例如：
public void testSum() {
assertEquals( 2, sum(1,1) );
}
TestCase.setUp() 和 TestCase.tearDown()是2个重要的方法，在每一个被测试方法运行前后被调用。
用以建立必要的测试环境亦即清理结果或释放资源，比如建立JDBC连接，或删除数据库中由前一个方法测试时，
插入的记录等。保证每个test方法，不受前一个test方法的影响。
一个完整的JUnit测试框架如下“图1”
图 1
Jbuilder7中Junit使用
图2
Junit建立一个方便使用的测试框架，但仍然需要使用者自己建立测试类。而当Jbuilder开发环境集成了Junit以后，
通过提供的程序向导，适得测试类也可以自动产生，使用者只需要添加少量代码即可完成，并将Junit测试环境集成在
Jbuilder的IDE开发环境之中，使用更为简便。在new 时的弹出的Object galley对话框中有一项Test页，用以支持Junit的使用。
见图2。
在Jbuilder中使用的junit的实例：
Step1:
首先建立一个普通的myCar类，代码如下：
package jbunitdemo;
public class myCar {
public int getWheels() {
return 4;
}
}
Step2:
New 时选择图2中的TestCase 项，弹出对话框(图3)
图 3
选择需要测试类，并可选择该类中需要测试的方法。然后可直接按Finish按钮。
产生Testcar类注意该类在/test/jbunitdemo路径下。
与src目录下的代码完全分离。向导中可选择进行运行环境注册，
也可手工Run->configuration菜单->弹出“Project Properties”对话框->选择Run分页->New按钮->弹出
Runtime Properties对话框->选择“Test分页”->在Main Class项中浏览需要运行的TestCase子类
或者TestSuite子类，起一个适当的Configuration name保存（见图4）。保存后可在工具栏Run按钮的下拉列表中，
显示你刚注册的运行环境名称。
图 4
将 TestmyCard.java文件的testGetWheels方法，最后增加一行
assertEquals(4,mycar.getWheels());
期待 mycar.getWheels()方法得到的结果等于4。
public void testGetWheels() {
myCar mycar = new myCar();
int intRet = mycar.getWheels();
/** @todo: Insert test code here. Use assertEquals(), for example. */
assertEquals(4,mycar.getWheels());
//用户自己增加的测试代码
}
运行菜单，选择相应的“运行环境名”点击即可运行。运行结果见图5，绿色表示通过测试，红色表示测试未通过。
图5
按照test方法的预定，就可以不断增加需要测试的情况，在test方法中使用适当assert方法进行判断被测程序的
行为是否符合预期。当出现“红叉”表示改种情况测试不通过，需要检查程序的出错原因。
写一个单元测试的代码，JBuilder环境基本可以完成60%-70%的代码量。用户所要做的
就是设置适当的输入情况，并判断相应的输出情况，来判断代码运行是否符合预期结果。
当类的数量逐渐增加时，类之间的调用关系也将变得复杂。当我们对一个类修改并测试完
成后，并不能保证其他类完全不受影响。 这就需要通过利用 TestSuite将多个有关联的
TestCase集成在一起。在Jbuilder环境中，你只需要通过向导提示，选择你所需要集成的
TestCase测试项目，几乎不需要写任何代码，就可完成集成回归测试。具体操作见“Jbulider帮助文件”
（见参考资源2），这里不展开详述。
示例DEMO 见JBUnitDemo目录，myCar.java，myCarport.java
实际工作类，TestmyCar.java用于测试myCar类，
TestmyCarport.java用于测试myCarport类，AllTest.java用于集成TestmyCar.java
与TestmyCarport.java这2个测试类。（见参考资源5）
Junit若干实践问题
1. 在EJB开发中如何使用JUnit？
Junit用于测试普通Java类，而EJB运行需要容器环境支持。在测试EJB组件时，可先建立EJB 客户端（在JBuilder中得到支持）
，然后使用启动EJB服务器组件，通过Junit对EJB客户端进行测试即可。目前有些junit的变种，可直接支持在EJB容器环境中，进行测试。
2. 在非JBuilder环境如何使用？
目前主流的Java开发工具，基本都集成了对Junit的支持。即使不使用IDE的开发环境，也完全可使用Junit，
但写测试用例时，代码量增加些。如果需要自动编译测试，可使用ant 工具。该工具已内置了对于junit的支持。
3. 在非Java环境中，如何使用XUnit工具?
由于JUnit在java开发中，广泛而成功的实践。陆续已经开发出其他语言环境中的Xunit版本（见 参考资源3）。
目前已经包括 C++环境和Object Pascal环境等多种环境。
JUnit实施
实施路线
从对JUnit基本介绍来看，JUnit工具本身并没有提出革命性的测试方法，更多的是对传统的测试方法的扩展与支持。
这就使得我们能够比较平滑的将Junit这一测试工具引入我们日常的开发活动中去。
第一阶段：单个开发人员，在具体模块代码写成以后，通过Junit对已完成的模块的代码编写测试用例。
用以验证完成代码的正确性。
（牵涉人员：单个程序员。代码范围：若干个不相关模块）
第二阶段：项目组内，若干个程序员达成共识，以测试用例做为补充文档。并能对一部分人的若干程序
模块的测试用例进行集成。
(牵涉人员：若干个程序员。代码范围：若干相互关联的模块)
第三阶段：项目组内基本达成共识，若干成员有一定的Junit使用经验。接受测试优先原则
（先写测试代码，后写实现代码）。将测试用例作为项目管理正式文档。
（牵涉范围：项目组骨干人员。 代码范围：核心模块）
第四阶段：全面导入XP(extreme programming)开发方式。将测试用例融入
，设计、编码、代码集成、系统重构全过程。使得开发过程平滑而可控。
(牵涉范围：全项目组，代码范围：项目的生命周期全过程)
不适用的范围
如同所有的优秀方法一样，Junit也有着自己的适用范围。一般以下情况不宜采用Junit。
1． 在相应的开发环境还没有类似的测试框架。比如J2ME等环境。
2． 程序设计不良，违反“高聚能、低偶合”等设计原则。或逻辑代码和界面操作混杂在一起。
无法写出相应测试用例。 这种情况下，需要改进设计本身。
成功案例
目前广泛使用的Jboss EJB服务器，就采用了ant和junit进行自动测试。Jboss发布版本的doc目录下
有个tests子目录，其中就存放着当前jboss版本使用Junit的测试报告。（见参考资源6）
结束语
1. 普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。
不管怎么样，重要的是先去尝试。
富兰克林D. 罗斯福1
It is common sense to take a method and try it. If it fails, admit it frankly
and try another. But above all, try something.
- FRANKLIN D. ROOSEVELT1
2. 没有银弹。
F.Brooks
（意为：没有无坚不摧的利器，没有万能的灵药。）
No Sliver Bullet.
Frederick P. Brooks
参考资源
1.Junit主页 http://www.junit.org/index.htm
2.Jbuilder环境中junit的使用文档。 Jbuilder 7 Help KeyWord: JUnit
3.下载 xUnit 测试工具 http://www.xprogramming.com/software.htm
4.XP介绍性文章 《XP 精华如何 java项目获得更大成功》
http://www-900.ibm.com/developerWorks/cn/java/j-xp/index.shtml
5.Jbuilder 7 JunitDEMO ：/JBUnitDemo 目录
6. Jboss 的test文档 ： / Jbosstests 目录
(本文完)
Jbuilder 集成了junit后使用很便捷，但对从没使用过
的人来说毕竟还是有些门槛。
原文是word格式，不知道怎么在“大富翁”上发布。
只能另存为txt格式。图片、DEMO都无法上传，排版也不好。
但本着“重在搀乎”的原则，还是发布一个txt版本。
=================================================
JUnit 使用介绍
作者： tuti tut@citiz.net
关键字：单元测试， 框架 ，JUnit
版本 1.0
JUnit 使用介绍 1
什么是单元测试(Unit Test) 1
常见的工作场景 2
场景1： 2
场景2： 2
场景3： 2
Java程序的传统测试方法： 3
Main测试法弊端： 3
理想中的单元测试的一些特征： 3
JUnit 使用介绍 3
测试框架 3
JUnit介绍 3
JUnit结构 4
Jbuilder7中Junit使用 5
Junit若干实践问题 8
JUnit实施 9
实施路线 9
不适用的范围 9
成功案例 10
结束语 10
参考资源 10
我们所要做的一切是尽可能快地犯错误。
——约翰.阿奇博尔德.惠勒
什么是单元测试(Unit Test)
程序设计领域中有很多种测试，单元测试只是其中的一种。
测试只能找到程序中的部分错误，难以保证程序完全正确无误。
单元测试定义：单元测试是在软件开发过程中，要进行的最低级别的测试活动，
在单元测试活动中，软件的独立将在与程序的其他部分相隔离的情况下进行测试。
完成单元测试是开发人员的日常工作，它是由程序员自己进行的测试工作。
单元测试所测试的是“程序代码单元是否按照预设的方式执行而产生的合乎期待的结果”，也就是程序代码的正确性。
单元测试的必要性：还有必要讨论吗？
常见的工作场景
场景1：
甲： 你那个“解析表达式”模块完成了怎么样?
乙： 代码已经完成了，但还没测试，我现在很忙，等我把剩下的模块全部完成了再来测试。
甲： 那当你完成了 90%。 心想：“但愿如此。。。”（悬！）
分析：
1． 单元测试实现起来需要简单方便，否则没人愿意做完整测试。
2． 没有测试的进度估算，失真的可能性很大。
场景2：
甲： 我需要使用你的那个“解析表达式”的模块。你的模块测试了吗？
乙： 测试过了。
甲： 都测试了哪些情况？
乙： 除了没测试的，都测试过了。
甲：(晕!) 那测试文档有吗？
乙： 很忙，没时间写。
甲： （再晕！）
分析：
1． 对于接口程序，需要能完整的描述接口的行为。
2． 需要可读性良好的资料，使与该程序的相关各方面，能进行良好的沟通。
场景3：
乙： 那个“解析表达式”的模块，效率太低，写得又乱，我想重写一下。
甲： 现在起码还能用，快交货了，你就老实点吧，别又搞出点BUG来。
乙： （郁闷!）
分析：
1． 在没有完整的测试安全网的情况下，对代码进行修改的风险很大。
Java程序的传统测试方法：
就一般java程序而言，程序员大多利用的在相应需要测试的类中添加main函数。
在main函数中，建立对象实例，调用需要测试的方法并打印结果。程序员通过打
印出来的结果，来判断执行是否准确。
Main测试法弊端：
1． 在需要交货的程序中，混杂有多余的代码。
2． 很难进行多了个类的集成测试。
3． 过多的打印语句不利于判断测试结果。
4． 逐个执行每个类的main方法，工作量很大。
理想中的单元测试的一些特征：
1． 完成一个测试，只需要少量测试代码。
2． 多个测试可以集成，进行回归测试。
3． 测试代码，和被测试代码完全分离。
4． 测试的自动化、快速，测试结果一目了然。
5． 测试代码有良好的可读性，具备文档作用，便于各方沟通。
JUnit 使用介绍
测试框架
为了达到以上理想中的单元测试，单个类或对象很难达到目的，而需要使用单元测试框架。
框架（framework）是指构成一组特定软件可复用设计的一组相互协作的类。
框架规定了你的应用的体系结构。它定义了整体结构，类和对象的分割，各部分的主要
责任类和对象是怎么协作，以及控制流程。框架预定意义了这些设计参数，以便于应用
设计者或实现者能集中精力于应用本身的细节。
JUnit介绍
目前在Java开发社区中，JUnit是最为流行的测试框架。而且Junit是开放源代码的，不需要购买。
打开JUnit的官方网站http://www.junit.org 是这样来介绍Junit“JUnit是由Erich Gamma、
Kent Beck所写的用于回归测试的框架”。 而Erich Gamma是《Design Partterns》的主要作者，
Kent Beck是“Extrme Programming”运动的主要旗手。
都是软件开发领域的重量级人物。（XP的简介见 参考资源4）
JUnit结构
Junit 提供了junit.framework.TestCase ， junit.framework.TestSuite基础类用来编写单元测试。
提供3个运行器(runnners), TestUI, SwingUI, AwtUI,来查看测试结果。TestCase和TestSuite都实现
了Test接口。不同之处在于，TestCase用以容纳一个个独立的Test方法,test suite用以将一系列相关的
test cases编成一个组。一个test Suite 可以容纳 若干个 test case和test suite。TestCase 可以
进行针对一个类的单元测试。TestSuite对TestCase进行了编组以后就可以对多个类进行回归测试。
Junit使用 断言（Assert）语句来进行结果的真伪判断。类似MFC中的ASSERT宏。
断言语句在junit.framework.Assert包中，例如：
assertEquals() 判断是否对象是否相等。
assertTrue() 判断boolean型的真伪。
assertNotNull() 判断对象是否不为空。
建立一个新的单元测试时，需建立一个TestCase的子类，在类中添加自定义的测试方法。测试方法名需要以 test来头，
如testSum( )。一个testXXX的测试方法，必须是 public方法，无返回值，无参数。在测试方法中，使用的适当的
断言语句，即完成了一个测试方法。
例如：
public void testSum() {
assertEquals( 2, sum(1,1) );
}
TestCase.setUp() 和 TestCase.tearDown()是2个重要的方法，在每一个被测试方法运行前后被调用。
用以建立必要的测试环境亦即清理结果或释放资源，比如建立JDBC连接，或删除数据库中由前一个方法测试时，
插入的记录等。保证每个test方法，不受前一个test方法的影响。
一个完整的JUnit测试框架如下“图1”
图 1
Jbuilder7中Junit使用
图2
Junit建立一个方便使用的测试框架，但仍然需要使用者自己建立测试类。而当Jbuilder开发环境集成了Junit以后，
通过提供的程序向导，适得测试类也可以自动产生，使用者只需要添加少量代码即可完成，并将Junit测试环境集成在
Jbuilder的IDE开发环境之中，使用更为简便。在new 时的弹出的Object galley对话框中有一项Test页，用以支持Junit的使用。
见图2。
在Jbuilder中使用的junit的实例：
Step1:
首先建立一个普通的myCar类，代码如下：
package jbunitdemo;
public class myCar {
public int getWheels() {
return 4;
}
}
Step2:
New 时选择图2中的TestCase 项，弹出对话框(图3)
图 3
选择需要测试类，并可选择该类中需要测试的方法。然后可直接按Finish按钮。
产生Testcar类注意该类在/test/jbunitdemo路径下。
与src目录下的代码完全分离。向导中可选择进行运行环境注册，
也可手工Run->configuration菜单->弹出“Project Properties”对话框->选择Run分页->New按钮->弹出
Runtime Properties对话框->选择“Test分页”->在Main Class项中浏览需要运行的TestCase子类
或者TestSuite子类，起一个适当的Configuration name保存（见图4）。保存后可在工具栏Run按钮的下拉列表中，
显示你刚注册的运行环境名称。
图 4
将 TestmyCard.java文件的testGetWheels方法，最后增加一行
assertEquals(4,mycar.getWheels());
期待 mycar.getWheels()方法得到的结果等于4。
public void testGetWheels() {
myCar mycar = new myCar();
int intRet = mycar.getWheels();
/** @todo: Insert test code here. Use assertEquals(), for example. */
assertEquals(4,mycar.getWheels());
//用户自己增加的测试代码
}
运行菜单，选择相应的“运行环境名”点击即可运行。运行结果见图5，绿色表示通过测试，红色表示测试未通过。
图5
按照test方法的预定，就可以不断增加需要测试的情况，在test方法中使用适当assert方法进行判断被测程序的
行为是否符合预期。当出现“红叉”表示改种情况测试不通过，需要检查程序的出错原因。
写一个单元测试的代码，JBuilder环境基本可以完成60%-70%的代码量。用户所要做的
就是设置适当的输入情况，并判断相应的输出情况，来判断代码运行是否符合预期结果。
当类的数量逐渐增加时，类之间的调用关系也将变得复杂。当我们对一个类修改并测试完
成后，并不能保证其他类完全不受影响。 这就需要通过利用 TestSuite将多个有关联的
TestCase集成在一起。在Jbuilder环境中，你只需要通过向导提示，选择你所需要集成的
TestCase测试项目，几乎不需要写任何代码，就可完成集成回归测试。具体操作见“Jbulider帮助文件”
（见参考资源2），这里不展开详述。
示例DEMO 见JBUnitDemo目录，myCar.java，myCarport.java
实际工作类，TestmyCar.java用于测试myCar类，
TestmyCarport.java用于测试myCarport类，AllTest.java用于集成TestmyCar.java
与TestmyCarport.java这2个测试类。（见参考资源5）
Junit若干实践问题
1. 在EJB开发中如何使用JUnit？
Junit用于测试普通Java类，而EJB运行需要容器环境支持。在测试EJB组件时，可先建立EJB 客户端（在JBuilder中得到支持）
，然后使用启动EJB服务器组件，通过Junit对EJB客户端进行测试即可。目前有些junit的变种，可直接支持在EJB容器环境中，进行测试。
2. 在非JBuilder环境如何使用？
目前主流的Java开发工具，基本都集成了对Junit的支持。即使不使用IDE的开发环境，也完全可使用Junit，
但写测试用例时，代码量增加些。如果需要自动编译测试，可使用ant 工具。该工具已内置了对于junit的支持。
3. 在非Java环境中，如何使用XUnit工具?
由于JUnit在java开发中，广泛而成功的实践。陆续已经开发出其他语言环境中的Xunit版本（见 参考资源3）。
目前已经包括 C++环境和Object Pascal环境等多种环境。
JUnit实施
实施路线
从对JUnit基本介绍来看，JUnit工具本身并没有提出革命性的测试方法，更多的是对传统的测试方法的扩展与支持。
这就使得我们能够比较平滑的将Junit这一测试工具引入我们日常的开发活动中去。
第一阶段：单个开发人员，在具体模块代码写成以后，通过Junit对已完成的模块的代码编写测试用例。
用以验证完成代码的正确性。
（牵涉人员：单个程序员。代码范围：若干个不相关模块）
第二阶段：项目组内，若干个程序员达成共识，以测试用例做为补充文档。并能对一部分人的若干程序
模块的测试用例进行集成。
(牵涉人员：若干个程序员。代码范围：若干相互关联的模块)
第三阶段：项目组内基本达成共识，若干成员有一定的Junit使用经验。接受测试优先原则
（先写测试代码，后写实现代码）。将测试用例作为项目管理正式文档。
（牵涉范围：项目组骨干人员。 代码范围：核心模块）
第四阶段：全面导入XP(extreme programming)开发方式。将测试用例融入
，设计、编码、代码集成、系统重构全过程。使得开发过程平滑而可控。
(牵涉范围：全项目组，代码范围：项目的生命周期全过程)
不适用的范围
如同所有的优秀方法一样，Junit也有着自己的适用范围。一般以下情况不宜采用Junit。
1． 在相应的开发环境还没有类似的测试框架。比如J2ME等环境。
2． 程序设计不良，违反“高聚能、低偶合”等设计原则。或逻辑代码和界面操作混杂在一起。
无法写出相应测试用例。 这种情况下，需要改进设计本身。
成功案例
目前广泛使用的Jboss EJB服务器，就采用了ant和junit进行自动测试。Jboss发布版本的doc目录下
有个tests子目录，其中就存放着当前jboss版本使用Junit的测试报告。（见参考资源6）
结束语
1. 普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。
不管怎么样，重要的是先去尝试。
富兰克林D. 罗斯福1
It is common sense to take a method and try it. If it fails, admit it frankly
and try another. But above all, try something.
- FRANKLIN D. ROOSEVELT1
2. 没有银弹。
F.Brooks
（意为：没有无坚不摧的利器，没有万能的灵药。）
No Sliver Bullet.
Frederick P. Brooks
参考资源
1.Junit主页 http://www.junit.org/index.htm
2.Jbuilder环境中junit的使用文档。 Jbuilder 7 Help KeyWord: JUnit
3.下载 xUnit 测试工具 http://www.xprogramming.com/software.htm
4.XP介绍性文章 《XP 精华如何 java项目获得更大成功》
http://www-900.ibm.com/developerWorks/cn/java/j-xp/index.shtml
5.Jbuilder 7 JunitDEMO ：/JBUnitDemo 目录
6. Jboss 的test文档 ： / Jbosstests 目录
(本文完)
]
]