要创建测试用例，我们要在ComplexTest类中添加包含我们要执行的assertion的方法。测试方法名以“test”开始，并且必须是public修饰的（public 类型）。只有这样JUnit才能通过Java的反射机制来调用它。我们接下来要测试的是对象的判等在我们的Complex类中重写了java.lang.Object的equals()方法，加法和乘法。
Figure 1（b）展示了上述几个测试方法的实现。
我们可以用任何的Java原始类中都定义的assertEquals方法。（The assertEquals method is overloaded and defined for all Java primitives, apart from Java objects.这里的assertEquals()方法重写和定义了所有Java原始类中的定义。）也可以用assertTrue和assertFalse来测试条件；用assertNull和assertNotNull来判断是否为空的引用；assertSame和assertNotSame来测试两个对象是否指向同一个引用。
接下来就要开始运行测试了。最简单的方法就是让JUnit通过反射机制来找到预定义的测试用例。当然也可以通过编写一些其他的代码来静态指定要使用的测试用例。要用反射机制来动态指定要运行的测试用例，我们只需要像Figure 1（c）一样在ComplexTest类中添加一个Testsuite()方法。
三、运行测试
运行测试时，我们不需要为Complex类添加任何一行代码。事实上，在以测试驱动的开发过程中，是先编写测试，然后写具体的类的实现。当然一开始就编写类的代码也不会有任何的问题。JUnit的相关信息可以在www.JUnit.org上找到。这个站点中有很多文档，包括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.”，意思为，保持条为绿色，也就得到了良好的代码。如果出现了错误，条就会变称红色，同时会出现一个关于失败测试的详细信息。如果你更喜欢文本界面，可以通过如下命令调用：
java -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（www.beust.com/testng）是近来兴起的一个JUnit的替代品，吸引了很多开发者的注意，ParaSoft的Jtest（www.parasoft.com/jtest）是一个流行并且经济的测试工具。在表格中把上述工具和JUnit进行了比较。
在表格中，我们可以看到Jtest提供了额外的一些特性，而这些特性你可能会认为只有那些比开源软件大100倍的商业软件才能拥有。不管怎样，这写额外的特性反映了一些不同的理念。本质上，JUnit是一个很简单的类库。事实上，如果你愿意，你可以从头开始写。JUnit在设计的时候，被设计为只用来做一件事情，但是一定要做好它。这个理念和Unix的工具的理念非常类似：让开发人员可以放入工具箱中，从而得到额外的功能。几个常见的JUnit例子有：JTestCase (http://jtestcase.sourceforge.net)
JUnitDoclet(www.JUnitdoclet.org)
JUnitPerf (www.clarkware.com/software/JUnitPerf.html)
MockObjects(www.mockobjects.com)
EasyMock (www.easymock.org)。
而另一方面，商业的测试框架则提供了尽可能多的功能和综合环境。
五、测试覆盖
在编码和测试的过程中，你必须确认所有的代码都被测试到了。JUnit能帮助编写测试，然而选择一个完整的测试集却依赖于每一个程序员。在测试中有很多种测试覆盖。例如语句覆盖（也被称为线性覆盖），结果覆盖（也被称为分支覆盖或路径覆盖）等等。如果你正在为一个开源项目工作，就能得到Clover（http://www.cenqua.com/clover/）这是一个商业的测试覆盖工具，但遵循了非商业的许可证。另外一个商业的测试覆盖工具Jcoverage (www.jcoverage.com)拥有一个遵循GPL的版本，但在功能上有所限制。GroboUtils (http://groboutils.sourceforge.net)包含了一个覆盖分析的包。Emma (http://emma.sourceforge.net)是另外一个易用的工具。两个JUnit特有的工具包是NoUnit (http://nounit.sourceforge.net/using.html) 和 Jester (http://jester.sourceforge.net)。GNU的编译器网站也包含了一个叫GCov的工具。
六、开发过程种的单元测试
援引Glenford Myers关于测试的经典书中的一句话：不要丢弃测试用例，除非程序被丢弃（"Avoid throwaway test cases unless the program is truly a throwaway program."见JUnit Resources栏）。你必须让你的代码和测试保持同步，做到这一点，无论什么时候代码改变了，回归测试都很简单。
用心计划的测试集合能创建非常有效的项目文档。看一个类如何运行的最好办法就是看它的运行，而单元测试用例包含的代码片断则正好能满足这一点。
一个综合的测试集合并不会浪费运行资源，因为测试代码不会干扰程序。但是测试会消耗一定的编译时的资源，不断增加的测试用例能拖慢编译的过程，要避免这个状况，开发人员可以按需要定制编译过程来完成系统的构建。比如可以用Ant来定义一组测试任务，这些任务能在每天结束的时候，在代码提交以前执行。
当然，单元测试只是测试环节中的很小一部分。除单元测试以外，我们还有将某一功能相关的代码一起执行测试，这就是功能测试，功能测试下面以后，就是整个系统的测试（系统测试）；在交付以前，最终用户会看软件是否达到了预定的需求（接受测试）等等。但是为软件的最小部分测试添加很多的舒适和乐趣会给后面的测试打下结实的基础。
