即便测试如例示的那样简单，你也有可能不愿在每次测试的时候都敲入上面的命令，而希望在某个集成环境中(IDE)点击一下鼠标就能执行测试。后面的章节会介绍到这些问题。第二，如果没有一定的规范，测试类的编写将会成为另一个需要定义的标准。没有人希望查看别人是如何设计测试类的。如果每个人都有不同的设计测试类的方法，光维护被测试的类就够烦了，谁还顾得上维护测试类?另外有一点我不想提，但是这个问题太明显了，测试类的代码多于被测试的类!这是否意味这双倍的工作?不!1)不论被测试类-Car 的 getWheels 方法如何复杂，测试类-testCar 的testGetWheels 方法只会保持一样的代码量。2)提高软件的质量并解决软件熵这一问题并不是没有代价的。testCar就是代价。
我们目前所能做的就是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。最好IDE工具可以支持这些规范。 好了，你所需要的就是JUnit。一个Open Source的项目。用其主页上的话来说就是：“JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架(regression testing framework)。用于Java开发人员编写单元测试之用。”所谓框架就是 Erich Gamma 和 Kent Beck 定下了一些条条框框，你编写的测试代码必须遵循这个条条框框：继承某个类，实现某个接口。其实也就是我们前面所说的规范。好在JUnit目前得到了大多数软件工程师的认可。遵循JUnit我们会得到很多的支持。回归测试就是你不断地对所编写的代码进行测试：编写一些，测试一些，调试一些，然后循环这一过程，你会不断地重复先前的测试，哪怕你正编写其他的类，由于软件熵的存在，你可能在编写第五个类的时候发现，第五个类的某个操作会导致第二个类的测试失败。通过回归测试我们抓住了这条大Bug。
回归测试框架-JUnit
通过前面的介绍，我们对JUnit有了一个大概的轮廓。知道了它是干什么的。现在让我们动手改写上面的测试类testCar使其符合Junit的规范--能在JUnit中运行。
//执行测试的类(JUnit版)
import junit.framework.*;
public class testCar extends TestCase {
protected int expectedWheels;
protected Car myCar;
public testCar(String name) {
super(name);
}
protected void setUp() {
expectedWheels = 4;
myCar = new Car();
}
文章来源于领测软件测试网 https://www.ltesting.net/
