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来定义一组测试任务，这些任务能在每天结束的时候，在代码提交以前执行。
当然，单元测试只是测试环节中的很小一部分。除单元测试以外，我们还有将某一功能相关的代码一起执行测试，这就是功能测试，功能测试下面以后，就是整个系统的测试(系统测试);在交付以前，最终用户会看软件是否达到了预定的需求(接受测试)等等。但是为软件的最小部分测试添加很多的舒适和乐趣会给后面的测试打下结实的基础。
文章来源于领测软件测试网 https://www.ltesting.net/