单元测试

我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。

幸运的是，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

什么时候测试？单元测试越早越好，早到什么程度？极限编程(Extreme Programming,或简称XP)讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的直接返回一个合适值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。

关于桩代码，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以我的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。

有一种看法是，只测试类的接口（公有函数），不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写（inline函数），所有在源文件编写实现的函数都要进行测试（构造函数和析构函数除外）。

优点：

1、它是一种验证行为。

程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支援。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。

2、它是一种设计行为。

编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。

3、它是一种编写文档的行为。

单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

4、它具有回归性。

自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

代码编写

编辑

多数讲述单元测试的文章都是以Java为例，本文以C++为例，后半部分所介绍的单元测试工具也只介绍C++单元测试工具。下面的示例代码的开发环境是VC6.0。

产品类

class CMyClass

{

public:

int Add(int i,int j);

CMyClass();

virtual ~CMyClass();

private:

int mAge; //年龄

CString mPhase; //年龄阶段，如"少年"，"青年"

};

建立对应的测试类CMyClassTester，为了节约编幅，只列出源文件的代码：

void CMyClassTester::CaseBegin()

{

//pObj是CMyClassTester类的成员变量，是被测试类的对象的指针，

//为求简单，所有的测试类都可以用pObj命名被测试对象的指针。

pObj = new CMyClass();

}

void CMyClassTester::CaseEnd()

{

delete pObj;

}

测试类的函数CaseBegin()和CaseEnd()建立和销毁被测试对象，每个测试用例的开头都要调用CaseBegin()，结尾都要调用CaseEnd()。

产品函数

接下来，我们建立示例的产品函数：

int CMyClass::Add(int i,int j)

{

return i+j;

}

和对应的测试函数：

void CMyClassTester::Add_int_int()

{

}

把参数表作为函数名的一部分，这样当出现重载的被测试函数时，测试函数不会产生命名冲突。下面添加测试用例：

void CMyClassTester::Add_int_int()

{

//第一个测试用例

CaseBegin();{ //1

int i = 0; //2

int j = 0; //3

int ret = pObj->Add(i,j); //4

ASSERT(ret == 0); //5

}CaseEnd(); //6

}

解释

第1和第6行建立和销毁被测试对象，所加的{}是为了让每个测试用例的代码有一个独立的域，以便多个测试用例使用相同的变量名。

第2和第3行是定义输入数据，第4行是调用被测试函数，这些容易理解，不作进一步解释。第5行是预期输出，它的特点是当实际输出与预期输出不同时自动报错，ASSERT是VC的断言宏，也可以使用其他类似功能的宏，使用测试工具进行单元测试时，可以使用该工具定义的断言宏。

示例中的格式显得很不简洁，2、3、4、5行可以合写为一行：ASSERT(pObj->Add(0,0) == 0);但这种不简洁的格式却是老纳极力推荐的，因为它一目了然，易于建立多个测试用例，并且具有很好的适应性，同时，也是极佳的代码文档，总之，老纳建议：输入数据和预期输出要自成一块。

建立了第一个测试用例后，应编译并运行测试，以排除语法错误，然后，使用拷贝/修改的办法建立其他测试用例。由于各个测试用例之间的差别往往很小，通常只需修改一两个数据，拷贝/修改是建立多个测试用例的最快捷办法。

测试用例

编辑

下面说说测试用例、输入数据及预期输出。输入数据是测试用例的核心，对输入数据的定义是：被测试函数所读取的外部数据及这些数据的初始值。外部数据是对于被测试函数来说的，实际上就是除了局部变量以外的其他数据，老纳把这些数据分为几类：参数、成员变量、全局变量、IO媒体。IO媒体是指文件、数据库或其他储存或传输数据的媒体，例如，被测试函数要从文件或数据库读取数据，那么，文件或数据库中的原始数据也属于输入数据。一个函数无论多复杂，都无非是对这几类数据的读取、计算和写入。预期输出是指：返回值及被测试函数所写入的外部数据的结果值。返回值就不用说了，被测试函数进行了写操作的参数（输出参数）、成员变量、全局变量、IO媒体，它们的预期的结果值都是预期输出。一个测试用例，就是设定输入数据，运行被测试函数，然后判断实际输出是否符合预期。下面举一个与成员变量有关的例子：

产品函数

void CMyClass::Grow(int years)

{

mAge += years;

if(mAge < 10)

mPhase = "儿童";

else if(mAge <20)

mPhase = "少年";

else if(mAge <45)

mPhase = "青年";

else if(mAge <60)

mPhase = "中年";

else

mPhase = "老年";

}

测试函数中的一个测试用例：

CaseBegin();{

int years = 1;

pObj->mAge = 8;

pObj->Grow(years);

ASSERT( pObj->mAge == 9 );

ASSERT( pObj->mPhase == "儿童" );

}CaseEnd();

在输入数据中对被测试类的成员变量mAge进行赋值，在预期输出中断言成员变量的值。现在可以看到老纳所推荐的格式的好处了吧，这种格式可以适应很复杂的测试。在输入数据部分还可以调用其他成员函数，例如：执行被测试函数前可能需要读取文件中的数据保存到成员变量，或需要连接数据库，老纳把这些操作称为初始化操作。例如，上例中 ASSERT( ...)之前可以加pObj->OpenFile();。为了访问私有成员，可以将测试类定义为产品类的友元类。例如，定义一个宏：

#define UNIT_TEST(cls) friend class cls##Tester;

然后在产品类声明中加一行代码：UNIT_TEST(ClassName)。

测试用例设计

下面谈谈测试用例设计。前面已经说了，测试用例的核心是输入数据。预期输出是依据输入数据和程序功能来确定的，也就是说，对于某一程序，输入数据确定了，预期输出也就可以确定了，至于生成/销毁被测试对象和运行测试的语句，是所有测试用例都大同小异的，因此，我们讨论测试用例时，只讨论输入数据。

前面说过，输入数据包括四类：参数、成员变量、全局变量、IO媒体，这四类数据中，只要所测试的程序需要执行读操作的，就要设定其初始值，其中，前两类比较常用，后两类较少用。显然，把输入数据的所有可能取值都进行测试，是不可能也是无意义的，我们应该用一定的规则选择有代表性的数据作为输入数据，主要有三种：正常输入，边界输入，非法输入，每种输入还可以分类，也就是平常说的等价类法，每类取一个数据作为输入数据，如果测试通过，可以肯定同类的其他输入也是可以通过的。下面举例说明：

正常输入

例如字符串的Trim函数，功能是将字符串前后的空格去除，那么正常的输入可以有四类：前面有空格；后面有空格；前后均有空格；前后均无空格。

边界输入

上例中空字符串可以看作是边界输入。

再如一个表示年龄的参数，它的有效范围是0-100，那么边界输入有两个：0和100。

非法输入

非法输入是正常取值范围以外的数据，或使代码不能完成正常功能的输入，如上例中表示年龄的参数，小于0或大于100都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类：文件不存在；目录不存在；文件正在被其他程序打开；权限错误。

如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。实际上，单元测试与代码编写是“一体两面”的关系，编码时对上述三种输入都是必须考虑的，否则代码的健壮性就会成问题。

白盒覆盖

上面所说的测试数据都是针对程序的功能来设计的，就是所谓的黑盒测试。单元测试还需要从另一个角度来设计测试数据，即针对程序的逻辑结构来设计测试用例，就是所谓的白盒测试。在老纳看来，如果黑盒测试是足够充分的，那么白盒测试就没有必要，可惜“足够充分”只是一种理想状态，例如：真的是所有功能点都测试了吗？程序的功能点是人为的定义，常常是不全面的；各个输入数据之间，有些组合可能会产生问题，怎样保证这些组合都经过了测试？难于衡量测试的完整性是黑盒测试的主要缺陷，而白盒测试恰恰具有易于衡量测试完整性的优点，两者之间具有极好的互补性，例如：完成功能测试后统计语句覆盖率，如果语句覆盖未完成，很可能是未覆盖的语句所对应的功能点未测试。

白盒测试针对程序的逻辑结构设计测试用例，用逻辑覆盖率来衡量测试的完整性。逻辑单位主要有：语句、分支、条件、条件值、条件值组合，路径。语句覆盖就是覆盖所有的语句，其他类推。另外还有一种判定条件覆盖，其实是分支覆盖与条件覆盖的组合，在此不作讨论。跟条件有关的覆盖就有三种，解释一下：条件覆盖是指覆盖所有的条件表达式，即所有的条件表达式都至少计算一次，不考虑计算结果；条件值覆盖是指覆盖条件的所有可能取值，即每个条件的取真值和取假值都要至少计算一次；条件值组合覆盖是指覆盖所有条件取值的所有可能组合。老纳做过一些粗浅的研究，发现与条件直接有关的错误主要是逻辑操作符错误，例如：||写成&&，漏了写！什么的，采用分支覆盖与条件覆盖的组合，基本上可以发现这些错误，另一方面，条件值覆盖与条件值组合覆盖往往需要大量的测试用例，因此，在老纳看来，条件值覆盖和条件值组合覆盖的效费比偏低。效费比较高且完整性也足够的测试要求是这样的：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。做过单元测试的朋友恐怕会对老纳提出的测试要求给予一个字的评价：晕！或者两个字的评价：狂晕！因为这似乎是不可能的要求，要达到这种测试完整性，其测试成本是不可想象的，不过，出家人不打逛语，老纳之所以提出这种测试要求，是因为利用一些工具，可以在较低的成本下达到这种测试要求，后面将会作进一步介绍。

关于白盒测试用例的设计，程序测试领域的书籍一般都有讲述，普通方法是画出程序的逻辑结构图如程序流程图或控制流图，根据逻辑结构图设计测试用例，这些是纯粹的白盒测试，不是老纳想推荐的方式。老纳所推荐的方法是：先完成黑盒测试，然后统计白盒覆盖率，针对未覆盖的逻辑单位设计测试用例覆盖它，例如，先检查是否有语句未覆盖，有的话设计测试用例覆盖它，然后用同样方法完成条件覆盖、分支覆盖和路径覆盖，这样的话，既检验了黑盒测试的完整性，又避免了重复的工作，用较少的时间成本达到非常高的测试完整性。不过，这些工作可不是手工能完成的，必须借助于工具，后面会介绍可以完成这些工作的测试工具。

测试工具

编辑

现在开始介绍单元测试工具，分别按编程语言进行分组介绍。

C/C++

CppUnit

首先是CppUnit，这是C++单元测试工具的鼻祖，免费的开源的单元测试框架。由于已有一众高人写了不少关于CppUnit的很好的文章，老纳就不现丑了，想了解CppUnit的朋友，建议读一下Cpluser 所作的《CppUnit测试框架入门》，。该文也提供了CppUnit的下载地址。

C++Test

然后介绍C++Test，这是Parasoft公司的产品。[C++Test是一个功能强大的自动化C/C++单元级测试工具，可以自动测试任何C/C++函数、类，自动生成测试用例、测试驱动函数或桩函数，在自动化的环境下极其容易快速的将单元级的测试覆盖率达到100%]。[]内的文字引自，这是华唐公司的网页。老纳想写些介绍C++Test的文字，但发现无法超越华唐公司的网页上的介绍，所以也就省点事了，想了解C++Test的朋友，建议访问该公司的网站。华唐公司代理C++Test，想要购买或索取报价、试用版都可以找他们。

Visual Unit

最后介绍Visual Unit，简称VU，这是国产的单元测试工具，据说申请了多项专利，拥有一批创新的技术，不过老纳只关心是不是有用和好用。[自动生成测试代码 快速建立功能测试用例程序行为一目了然 极高的测试完整性 高效完成白盒覆盖 快速排错 高效调试 详尽的测试报告]。[]内的文字是VU开发商的网页上摘录的，。前面所述测试要求：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖，用VU可以轻松实现，还有一点值得一提：使用VU还能提高编码的效率，总体来说，在完成单元测试的同时，编码调试的时间还能大幅度缩短。算了，不想再讲了，老纳显摆理论、介绍经验还是有兴趣的，因为可以满足老纳好为人师的虚荣心，但介绍工具就觉得索然无味了，毕竟工具好不好用，合不合用，要试过才知道，还是自己去开发商的网站看吧，可以下载演示版，还有演示课件。

gtest

gtest测试框架是在不同平台上（Linux，Mac OS X，Windows，Cygwin，Windows CE和Symbian）为编写C++测试而生成的。它是基于xUnit架构的测试框架，支持自动发现测试，丰富的断言集，用户定义的断言，death测试，致命与非致命的失败，类型参数化测试，各类运行测试的选项和XML的测试报告。需要详细了解的朋友可以参阅《玩转Google单元测试框架gtest系列》该篇文章。

C#

Visual Build Professional

Java

JUnit

JUnit 是 Java 社区中知名度最高的单元测试工具。它诞生于 1997 年，由 Erich Gamma 和 Kent Beck 共同开发完成。其中 Erich Gamma 是经典著作《设计模式：可复用面向对象软件的基础》一书的作者之一，并在 Eclipse 中有很大的贡献；Kent Beck 则是一位极限编程（XP）方面的专家和先驱。JUnit 设计的非常小巧，但是功能却非常强大。JUnit ——是一个开发源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。主要用于白盒测试，回归测试。

JUnit的好处和JUnit单元测试编写原则：

好处：可以使测试代码与产品代码分开；针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试；易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发；JUnit是公开源代码的，可以进行二次开发；可以方便地对JUnit进行扩展；

编写原则：是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；是使测试单元保持持久性；是可以利用既有的测试来编写相关的测试；

JUnit使用帮助

1、junit3.x版本，我们通常使用junit 3.8[2] 

(1)、使用junit3.x版本进行单元测试时，测试类必须要继承于TestCase父类；

(2)、测试方法需要遵循的原则：

A、public的

B、void的

C、无方法参数

D、方法名称必须以test开头

(3)、不同的Test Case之间一定要保持完全的独立性，不能有任何的关联。

(4)、我们要掌握好测试方法的顺序，不能依赖于测试方法自己的执行顺序。

dome:

public class TestMyNumber extends TestCase {

private MyNumber myNumber;

public TestMyNumber(String name) {

super(name);

}

// 在每个测试方法执行 [之前] 都会被调用

@Override

public void setUp() throws Exception {

// System.out.println("欢迎使用Junit进行单元测试…");

myNumber = new MyNumber();

}

// 在每个测试方法执行 [之后] 都会被调用

@Override

public void tearDown() throws Exception {

// System.out.println("Junit单元测试结束…");

}

public void testDivideByZero() {

Throwable te = null;

try {

myNumber.divide(6, 0);

Assert.fail("测试失败");

} catch (Exception e) {

e.printStackTrace();

te = e;

}

Assert.assertEquals(Exception.class, te.getClass());

Assert.assertEquals("除数不能为 0 ", te.getMessage());

}

}

2、junit4.x版本[2] 

(1)、使用junit4.x版本进行单元测试时，不用测试类继承TestCase父类，因为，junit4.x全面引入了Annotation来执行我们编写的测试。

(2)、junit4.x版本，引用了注解的方式，进行单元测试；

(3)、junit4.x版本我们常用的注解：

A、@Before 注解：与junit3.x中的setUp()方法功能一样，在每个测试方法之前执行；

B、@After 注解：与junit3.x中的tearDown()方法功能一样，在每个测试方法之后执行；

C、@BeforeClass 注解：在所有方法执行之前执行；

D、@AfterClass 注解：在所有方法执行之后执行；

E、@Test(timeout = xxx) 注解：设置当前测试方法在一定时间内运行完，否则返回错误；

F、@Test(expected = Exception.class) 注解：设置被测试的方法是否有异常抛出。抛出异常类型为：Exception.class；

G、@Ignore 注解：注释掉一个测试方法或一个类，被注释的方法或类，不会被执行。

dome:

package com.an.junit;

import static org.junit.Assert.*;

import org.junit.After;

import org.junit.AfterClass;

import org.junit.Before;

import org.junit.BeforeClass;

import org.junit.Test;

public class TestMyNumber {

private MyNumber myNumber;

@BeforeClass

// 在所有方法执行之前执行

public static void globalInit() {

System.out.println("init all method...");

}

@AfterClass

// 在所有方法执行之后执行

public static void globalDestory() {

System.out.println("destory all method...");

}

@Before

// 在每个测试方法之前执行

public void setUp() {

System.out.println("start setUp method");

myNumber = new MyNumber();

}

@After

// 在每个测试方法之后执行

public void tearDown() {

System.out.println("end tearDown method");

}

@Test(timeout=600)// 设置限定测试方法的运行时间 如果超出则返回错误

public void testAdd() {

System.out.println("testAdd method");

int result = myNumber.add(2, 3);

assertEquals(5, result);

}

@Test

public void testSubtract() {

System.out.println("testSubtract method");

int result = myNumber.subtract(1, 2);

assertEquals(-1, result);

}

@Test

public void testMultiply() {

System.out.println("testMultiply method");

int result = myNumber.multiply(2, 3);

assertEquals(6, result);

}

@Test

public void testDivide() {

System.out.println("testDivide method");

int result = 0;

try {

result = myNumber.divide(6, 2);

} catch (Exception e) {

fail();

}

assertEquals(3, result);

}

@Test(expected = Exception.class)

public void testDivide2() throws Exception {

System.out.println("testDivide2 method");

myNumber.divide(6, 0);

fail("test Error");

}

public static void main(String[] args) {

}

}

有兴趣的朋友可以下下来仔细研究下，也可以到安安DIY创作室博客一起讨论一下。

JUnit-addons

对JUnit的一些补充，比如设置、获取被测试对象的私有属性的值，调用被测试对象的私有方法等。

常用类：junitx.util.PrivateAccessor

Spring 测试框架

可以测试基于Spring的应用，通过配置文件和注解自动组装需要的单元测试对象。

提供了一些常用的J2EE Mock对象，比如HttpSession的Mock类等。

可以支持数据库自动回滚，以防止对数据库的单元测试（插入，删除等）不可重复执行，防止修改数据库状态等。

DJUnit

通过代码自动产生Mock对象，省去了自己手动编写N多的Mock类。

此外，它的Eclipse插件还可以做到测试覆盖率、分支统计。

EasyMock

功能同DJUnit，也是通过编程自动Mock掉与测试对象无关的类，方法。