应用junit进行单元测试

<!-- 正文begin -->

测试可以分类为：白箱测试、黑箱测试、单元测试、集成测试、功能测试...。白箱测试是指在知道被测试的软件如何（How）完成功能和完成什么样（What）的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员最了解自己编写的软件。黑箱测试则是指在知道被测试的软件完成什么样（What）的功能的条件下所作的测试。一般是由测试人员完成。

接下来我们介绍一下单元测试，单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合，协同完成特定的任务，目前我们暂不关心它。下面我所提到的测试，除非特别说明，一般都是指单元测试。

测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterative and incremental）的开发过程。Martin Fowler（有点儿像引用孔夫子的话）甚至认为：“在你不知道如何测试代码之前，就不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。

 

看下面的例子：
//将要被测试的类
public class Car {
    public int getWheels() {
return 4;
}
}

//执行测试的类
public class testCar {
public static void main（String[] args) {
testCar myTest = new testCar();
myTest.testGetWheels();
}

public testGetWheels() {
int expectedWheels = 4;
Car myCar = Car();
if (expectedWheels==myCar.getWheels()) 
System.out.println("test [Car]: getWheels works perfected!");
else
System.out.println("test [Car]: getWheels DOESN'T work!");
}
}

 

这样写的测试类有多个弊端：比如每次测试的时候都敲入上面的命令、如果没有一定的规范，测试类的编写将会成为另一个需要定义的标准、测试类的代码多于被测试的类。

为了避免以上，我们要做的就是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。最好IDE工具可以支持这些规范。JUnit应运而生了。

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();
}

public static Test suite() {
/*
 * the type safe way
 *
TestSuite suite= new TestSuite();
suite.addTest(
new testCar("Car.getWheels") {
 protected void runTest() { testGetWheels(); }
}
);
return suite;
*/

/*
 * the dynamic way
 */
return new TestSuite(testCar.class);
}

public void testGetWheels() {
assertEquals(expectedWheels, myCar.getWheels());
}
}
1>;import语句，引入JUnit的类
2>;继承 TestCase 。可以暂时将一个TestCase看作是对某个类进行测试的方法的集合。详细介绍请参看JUnit资料

3>;setUp()设定了进行初始化的任务。我们以后会看到setUp会有特别的用处。

4>;testGetWheeels()对预期的值和myCar.getWheels()返回的值进行比较，并打印比较的结果。assertEquals是junit.framework.Assert中所定义的方法，junit.framework.TestCase继承了junit.framework.Assert。

5>;suite()是一个很特殊的静态方法。JUnit的TestRunner会调用suite方法来确定有多少个测试可以执行。上面的例子显示了两种方法：静态的方法是构造一个内部类，并利用构造函数给该测试命名(test name, 如 Car.getWheels )，其覆盖的runTest()方法，指明了该测试需要执行那些方法－－testGetWheels()。动态的方法是利用内省（reflection ）来实现runTest()，找出需要执行那些测试。此时测试的名字即是测试方法（test method，如testGetWheels）的名字。JUnit会自动找出并调用该类的测试方法。

6>;将TestSuite看作是包裹测试的一个容器。如果将测试比作叶子节点的话，TestSuite就是分支节点。实际上TestCase，TestSuite以及TestSuite组成了一个composite Pattern。

 

转 自 http://www.chinaunix.net/jh/26/215124.html