测试驱动开发(TDD)是以测试作为开发过程的中心,它坚持,在编写实际代码之前,先写好基于产品代码的测试代码。开发过程的目标就是首先使测试能够通过,然后再优化设计结构。测试驱动开发式是极限编程的重要组成部分。XUnit,一个基于测试驱动开发的测试框架,它为我们在开发过程中使用测试驱动开发提供了一个方便的工具,使我们得以快速的进行单元测试。XUnit的成员有很多,如JUnit,PythonUnit等。今天给大家介绍的CppUnit即是XUnit家族中的一员,它是一个专门面向C++的测试框架。
本文不对CppUnit源码做详细的介绍,而只是对CppUnit的应用作一些介绍。你将看到:
本文叙述背景为:CppUnit1.12.0, Visual C++ 6.0, WindowsXP。文中叙述有误之处,敬请批评指正。
一. CppUnit的安装
从http://sourceforge.net/projects/cppunit CppUnit的源码包. CppUnit是开源产品 , 当前最高版本为1.12.0. (在上面的链接所指向的页面上选择 Development Snapshot ).
下载后,将源码包解压缩到本地硬盘,例如解压到E:/ cppunit-1.12.0。笔者把文件夹名称中的版本号去掉,即源码包解压缩到E:/cppunit。下载解压后,你将看到如下文件夹:
主要的文件夹有:
接下来进行编译工作。 在src/目录下, 将CppUnitLibraries.dsw工程文件用vc 打开。执行build/batch build,编译成功的话,生成的库文件将被拷贝到lib目录下。中途或者会有些project编译失败,一般不用管它,我们重点看的是cppunit和TestRunner 这两个project的debug和release版本。
编译通过以后, 在lib/目录下,会生成若干lib,和dll文件, 都以cppunit开头. cppunitd表示debug版, cppunit表示release版。
CppUnit为我们提供了两套框架库,一个为静态的lib,一个为动态的dll。cppunit project:静态lib;cppunit_dll project:动态dll和lib。在开发中我们可以根据实际情况作出选择。
你也可以根据需要选择所需的项目进行编译,其中项目cppunit为静态库,cppunit_dll为动态库,生成的库文件为:
另外一个需要关注的project是TestRunner,它输出一个dll,提供了一个基于GUI 方式的测试环境,在CppUnit下, 可以选择控制台方式和GUI方式两种表现方案。两种方案分别如下图所示:
我们选择GUI方式,所以我们也需要编译这个project,输出位置亦为lib文件夹。
要使用CppUnit,还得设置好头文件和库文件路径,以VC6为例,选择Tools/Options/Directories,在Include files和Library files中分别添加%CppUnitPath%/include和%CppUnitPath%/lib,其中%CppUnitPath%表示CppUnit所在路径。本文这里分别填的是E:/CPPUNIT/INCLUDE和E:/CPPUNIT/LIB。
二、概念
在使用之前,我们有必要认识一下CppUnit中的主要类,当然你也可以先看后面的例子,遇到问题再回过头来看这一节。
CppUnit核心内容主要包括一些关键类:
Test:所有测试对象的基类。
CppUnit采用树形结构来组织管理测试对象(类似于目录树,如下图所示),因此这里采用了组合设计模式(Composite Pattern),Test的两个直接子类TestLeaf和TestComposite分别表示“测试树”中的叶节点和非叶节点,其中TestComposite主要起组织管理的作用,就像目录树中的文件夹,而TestLeaf才是最终具有执行能力的测试对象,就像目录树中的文件。
Test最重要的一个公共接口为:
virtual void run(TestResult *result) = 0;
其作用为执行测试对象,将结果提交给result。
在实际应用中,我们一般不会直接使用Test、TestComposite以及TestLeaf,除非我们要重新定制某些机制。
TestFixture:用于维护一组测试用例的上下文环境。
在实际应用中,我们经常会开发一组测试用例来对某个类的接口加以测试,而这些测试用例很可能具有相同的初始化和清理代码。为此,CppUnit引入TestFixture来实现这一机制。
TestFixture具有以下两个接口,分别用于处理测试环境的初始化与清理工作:
virtual void setUp();
virtual void tearDown(); TestCase:测试用例,从名字上就可以看出来,它便是单元测试的执行对象。
TestCase从Test和TestFixture多继承而来,通过把Test::run制定成模板函数(Template Method)而将两个父类的操作融合在一起,run函数的伪定义如下:
// 伪代码 void TestCase::run(TestResult* result)
{ result->startTest(this); // 通知result测试开始
if( result->protect(this, &TestCase::setUp) ) // 调用setUp,初始化环境
result->protect(this, &TestCase::runTest); // 执行runTest,即真正的测试代码
result->protect(this, &TestCase::tearDown); // 调用tearDown,清理环境
result->endTest(this); // 通知result测试结束
}
这里要提到的是函数runTest,它是TestCase定义的一个接口,原型如下:
virtual void runTest();
用户需从TestCase派生出子类并实现runTest以开发自己所需的测试用例。
另外还要提到的就是TestResult的protect方法,其作用是对执行函数(实际上是函数对象)的错误信息(包括断言和异常等)进行捕获,从而实现对测试结果的统计。
TestSuit:测试包,按照树形结构管理测试用例
TestSuit是TestComposite的一个实现,它采用vector来管理子测试对象(Test),从而形成递归的树形结构。
TestFactory:测试工厂
这是一个辅助类,通过借助一系列宏定义让测试用例的组织管理变得自动化。参见后面的例子。
TestRunner:用于执行测试用例
TestRunner将待执行的测试对象管理起来,然后供用户调用。其接口为:
virtual void addTest( Test *test );
virtual void run( TestResult &controller, const std::string &testPath = "" );
这也是一个辅助类,需注意的是,通过addTest添加到TestRunner中的测试对象必须是通过new动态创建的,用户不能删除这个对象,因为TestRunner将自行管理测试对象的生命期。
三、CppUnit 的使用
以上工作完成以后,就可以正式使用CppUnit了,由于单元测试是TDD(测试驱动开发)的利器,一般人会先写测试代码,然后再写产品代码,不过笔者认为先写产品代码框架后再写测试代码,然后通过慢慢补充产品代码以使得能通过测试的方法会好些。不管先写谁只要写得舒服安全就可以。本文决定先写测试代码。
前面我们提到过,CppUnit最小的测试单位是TestCase,多个相关TestCase组成一个TestSuite。要添加测试代码最简单的方法就是利用CppUnit为我们提供的几个宏来进行(当然还有其他的手工加入方法,但均是殊途同归,大家可以查阅CppUnit头文件中的演示代码)。这几个宏是:
CPPUNIT_TEST_SUITE() 开始创建一个TestSuite;
CPPUNIT_TEST() 添加TestCase;
CPPUNIT_TEST_SUITE_END() 结束创建TestSuite;
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION() 添加一个TestSuite到一个指定的TestFactoryRegistry工厂。
感兴趣的朋友可以在HelperMacros.h看看这几个宏的声明,本文在此不做详述。
假定我们要实现一个类,类名暂且取做CPlus,它的功能主要是实现两个数相加(多简单的一个类啊,这也要测试吗?不要紧,我们只是了解怎样加入测试代码来测试它就行了,所以越简单越好)。 假定这个类要实现的相加的方法是:
int Add(int nNum1, int nNum2);
OK,那我们先来写测试这个方法的代码吧。TDD 可是先写测试代码,后写产品代码(CPlus)的哦!先写的测试代码往往是不能运行或编译的,我们的目标是在写好测试代码后写产品代码,使之编译通过,然后再进行重构。这就是Kent Beck说的“red/green/refactor”。所以,上面的类名和方法应该还只是在你的心里,还只是你的idea而已。
根据测试驱动的原理,我们需要先建立一个单元测试框架。我们在VC中为测试代码建立一个project。通常,测试代码和被测试对象(产品代码)是处于不同的project中的。这样就不会让你的产品代码被测试代码所“污染 ”。
由于在CppUnit下, 可以选择控制台方式和UI方式两种表现方案,我们选择UI方式。在本例中,我们将建立一个基于GUI 方式的测试环境。因此我们建立一个基于对话框的Project。假设名为UnitTest。
建立了UnitTest project之后,我们首先配置这个工程。
首先在project中打开RTTI开关,具体位置在菜单Project/Settings/C++/C++ Language。如下图所示设置:
由于CppUnit所用的动态运行期库均为多线程动态库,因此你的单元测试程序也得使用相应设置,否则会发生冲突。于是我们在Project/Settings/C++/Code Generation中进行如下设置:
在Use run-time library一栏中,针对debug和release分别设置为‘Debug Multithreaded DLL’和‘Multithreaded DLL’。如下图所示:
最后别忘了在project中link正确的lib。包括本例采用的cppunit.lib和cppunitd.lib静态库以及用于GUI方式的TestRunner.dll对应的lib。具体位置在Project/Settings/Link/General
在‘Object/library modules’中,针对debug和release分别加入cppunitd.lib testrunnerd.lib和cppunit.lib TestRunner.lib。如下图所示:
最后,由于TestRunner.dll为我们提供了基于GUI的测试环境。为了让我们的测试程序能正确的调用它,TestRunner.dll必须位于你的测试程序的路径下。所以把/lib目录下的testrunnerd.dll和TestRunner.dll文件分别拷贝到UnitTest priject的程序debug和release版本输出目录中。如下图所示:
(这是release版本)只要放在一起就可以了。
配置工作终于完成,下面开始写测试框架。
在CppUnit中, 是以TestCase为最小的测试单位, 若干TestCase组成一个TestSuite。所以我们要先建立一个TestCase。
在UnitTest project中新建一个类, 命名为CPlusTestCase, 让其从CppUnit::TestCase派生。为其新增一个方法,假设为 void testAdd(); 我们将在这个函数中写入我们的一些测试代码(还记得我们要测试的构想中的CPlus::Add(…)吗)。代码如下:切记要包含头文件
接下来, 我们要对我们的CPlusTestCase进行声明。声明用到了三个宏.
CPPUNIT_TEST_SUITE(); CPPUNIT_TEST(); CPPUNIT_TEST_SUITE_END();
第一个宏声明一个测试包(suite),第二个宏声明(添加)一个测试用例. 现在我们的CPlusTestCase类看上去象这样:切记要包含头文件,否则无法识别这些宏。
通过这几个宏,我们就把CPlusTestCase和testAdd注册到了测试列表当中。
接下来,我们要注册我们的测试suite. 使用CPPUNIT_TEST_SUITE_NAMED_REGISTRATION()来注册一个测试suite. 这个宏的第二个参数是我们注册的suite的名字. 在这里我们可以用字符串来代替, 但我们用一个静态函数来返回这个suite的名字.
记得要在PlusTestCase.h中包含 #include <string>
然后在 PlusTestCase.cpp注册我们的suite.
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(CPlusTestCase, CPlusTestCase::GetSuiteName());
它将CPlusTestCase这个TestSuite注册到一个指定的TestFactory工厂中。
接下来我们写一个注册函数static CppUnit::Test* GetSuite(), 使其在运行期生成一个Test.
记住在PlusTestCase.h中包含头文件:
#include <cppunit/extensions/TestFactoryRegistry.h>
最后, 我们为单元测试建立一个UI测试界面.
由于我们希望这个Project运行后显示的是GUI界面,所以我们需要在App的 InitInstance ()中屏蔽掉原有的对话框,代之以CppUnit的GUI。
我们在CUnitTestApp::InitInstance()函数中,将原先显示主对话框的代码以下面的代码取代:
切记必须先在UnitTest.cpp中包含头文件:
#include <cppunit/ui/mfc/TestRunner.h> #include " PlusTestCase.h "
到此为止, 我们已经建立好一个简单的单元测试框架。测试框架虽然写好了,但是测试代码仍然为空,产品代码也还没有写。下面我们来写测试代码:
如前所述,在测试类中,我们添加了一个测试方法:
void testAdd();
它测试的对象是前面提到的CPlus类的方法:int Add(int nNum1, int nNum2);(产品代码)我们来看看testAdd()的实现:记得在PlusTestCase.h中包含头文件
CPPUNIT_ASSERT_EQUAL是一个判断结果的宏。CppUnit中类似的其它宏请查阅TestAssert.h,本文在此不做详述 。
另外,我们还可以覆写基类的 setUp()、tearDown()两个函数。这两个函数实际上是一个模板方法,在测试运行之前会调用setUp()以进行一些初始化的工作,测试结束之后又会调用tearDown()来做一些“善后工作” ,比如资源的回收等等。当然,你也可以不覆写这两个函数,因为它们在基类里定义成了空方法,而不是纯虚函数。
编写完上面的测试代码后,进行编译。编译肯定通不过,编译器会告诉我们CPlus类没有声明,因为我们还没有实现CPlus类呢!现在的工作就是马上实现CPlus类,让编译通过。现在你应该嗅到一点“测试驱动”(Test Driven Develop)的味道了吧?
在VC中建立一个MFC Extension Dll的Project,在这个Project 中加入类CPlus,它的声明如下:
Add在Plus.cpp中实现如下
非常简单,不是吗?现在让前面那个包含测试代码的Project dependent这个Project,并且include 相关头文件 ,Rebuild All,你会发现编译已通过。你体会到了测试代码驱动产品代码了吗?当然我们的这个例子还很简单 ,没有重构这一步骤。
运行我们的测试程序,单击Browse,你就会看到如下图所示的界面:
选择CPlusTestCase::testAdd后,单击Run,你就会看到如下图所示的界面:
这下你应该对前面我们说的TestSuite的名字理解更深了吧。CPlus是一个测试包TestSuite,它的下面包含一个测试用例,这个测试用例下面又包含一个测试方法。
如果我修改CPlus::Add的代码如下:
重新编译通过,运行程序就会发现:
GUI显示有一个单元测试不通过,并显示出错的地方和原因,这样就很好的控制Bug了。
四、下面是完整的程序清单
五、参考资料