三、运行测试运行测试时，我们不需要为Complex类添加任何一行代码。事实上，在以测试驱动的开发过程中，是先编写测试，然后写具体的类的实现。当然一开始编写类的代码也不会有任何的问题。JUnit的相关信息可以在上找到。这个站点中有很多文档，包括Beck和Gamma原创的介绍JUnit的文章。JUnit的安装非常简单，只需要解压完成了。在编译的过程中，需要确保ClassPath中包含了JUnit所在的目录。假设你将程序放在/usr/java/JUnit下，编译的命令是javac –classpath “。：/usr/java/JUnit/JUnit.jar” ComplexTest.java.要运行测试，可以通过一下命令启动JUnit的图形界面：java -classpath “。：/usr/java/JUnit/JUnit.jar” JUnit.swingui.TestRunner 然后输入包含测试组的类名。接下来JUnit会进行测试，如果所有的测试都通过了，窗口上会出现一个绿色的滚动条，如Figure2所示（图略）。由此也有了JUnit的箴言：“Keep the bargreen to keep the code clean.”，意思为，保持条为绿色，也得到了良好的代码。如果出现了错误，条会变称红色，同时会出现一个关于失败测试的详细信息。如果你更喜欢文本界面，可以通过如下命令调用：wuhuif -classpath “。：/usr/java/JUnit/JUnit.jar” JUnit.textui. TestRunner ComplexTest，在中端窗口中会出现运行结果。
　　现在，你可以为Complex类添加更多的方法，比如一个复数的除法。与此同时，你也要为ComplexTest类添加一个测试用例，运行测试，然后纠正任何存在的错误，继续编码和测试。
　　四、JUnit的遗赠和竞争JUnit的成功激励了很多促进特殊代码测试的扩展的诞生。这些扩展的目标是对数据库代码、EJB，Servlets等进行测试。JUnit也能很好的和一些开发环境（工具）相结合。JUnit Ant Task允许Ant调用JUnit的测试任务（要了解更多关于Ant，见Nicholas Serrano 和 Ismael Ciordia 2004年11、12月份的专栏）。JUnit的官方网站上包括了很多JUnit的扩展和与之结合的开发环境的介绍和链接。
　　如果你喜欢开发语言不是Java，其他的语言也提供了JUnit类似的接口和框架，xUNIT的符号代表了整个家族：CppUnit负责C＋＋的单元测试；perlUnit是Perl的单元测试接口。PyUnit是Python语言的单元测试标准框架；Test：：Unit则控制了整个Ruby社区；Nunit是用C＃完成的，为。Net平台提供了开源的单元测试支持。
　　TestNG（/testng）是近来兴起的一个JUnit的替代品，吸引了很多开发者的注意，ParaSoft的Jtest（/jtest）是一个流行并且经济的测试工具。在表格中把上述工具和JUnit进行了比较。
　　在表格中，我们可以看到Jtest提供了额外的一些特性，而这些特性你可能会认为只有那些比开源软件大100倍的商业软件才能拥有。不管怎样，这写额外的特性反映了一些不同的理念。本质上，JUnit是一个很简单的类库。事实上，如果你愿意，你可以从头开始写。JUnit在设计的时候，被设计为只用来做一件事情，但是一定要做好它。这个理念和Unix的工具的理念非常类似：让开发人员可以放入工具箱中，从而得到额外的功能。几个常见的JUnit例子有：JTestCase
　　JUnitDoclet()
　　JUnitPerf (/software/l)
　　MockObjects()
　　EasyMock ()。
　　[NextPage]
　　而另一方面，商业的测试框架则提供了尽可能多的功能和综合环境。
　　五、测试覆盖
　　在编码和测试的过程中，你必须确认所有的代码都被测试到了。JUnit能帮助编写测试，然而选择一个完整的测试集却依赖于每一个程序员。在测试中有很多种测试覆盖。例如语句覆盖（也被称为线性覆盖），结果覆盖（也被称为分支覆盖或路径覆盖）等等。如果你正在为一个开源项目工作，能得到Clover
　　这是一个商业的测试覆盖工具，但遵循了非商业的许可证。另外一个商业的测试覆盖工具Jcoverage ()拥有一个遵循GPL的版本，但在功能上有所限制。GroboUtils ()包含了一个覆盖分析的包。Emma ()是另外一个易用的工具。两个JUnit特有的工具包是NoUnit () 和 Jester ()。GNU的编译器网站也包含了一个叫GCov的工具。
　　六、开发过程种的单元测试
　　援引Glenford Myers关于测试的经典书中的一句话：不要丢弃测试用例，除非程序被丢弃（"Avoid throwaway test cases unless the program is truly a throwaway program."见JUnit Resources栏）。你必须让你的代码和测试保持同步，做到这一点，无论什么时候代码改变了，回归测试都很简单。
　　用心计划的测试集合能创建非常有效的项目文档。看一个类如何运行的好办法是看它的运行，而单元测试用例包含的代码片断则正好能满足这一点。
　　一个综合的测试集合并不会浪费运行资源，因为测试代码不会干扰程序。但是测试会消耗一定的编译时的资源，不断增加的测试用例能拖慢编译的过程，要避免这个状况，开发人员可以按需要定制编译过程来完成系统的构建。比如可以用Ant来定义一组测试任务，这些任务能在每天结束的时候，在代码提交以前执行。
　　当然，单元测试只是测试环节中的很小一部分。除单元测试以外，我们还有将某一功能相关的代码一起执行测试，这是功能测试，功能测试下面以后，是整个系统的测试（系统测试）；在交付以前，终用户会看软件是否达到了预定的需求（接受测试）等等。但是为软件的小部分测试添加很多的舒适和乐趣会给后面的测试打下结实的基础。