CppUnit测试框架入门

CppUnit测试框架入门

作者:Jack Ho

下载源代码

  测试驱动开发(TDD)是以测试作为开发过程的中心,它坚持,在编写实际代码之前,先写好基于产品代码的测试代码。开发过程的目标就是首先使测试能够通过,然后再优化设计结构。测试驱动开发式是极限编程的重要组成部分。XUnit,一个基于测试驱动开发的测试框架,它为我们在开发过程中使用测试驱动开发提供了一个方便的工具,使我们得以快速的进行单元测试。XUnit的成员有很多,如JUnit,PythonUnit等。今天给大家介绍的CppUnit即是XUnit家族中的一员,它是一个专门面向C++的测试框架。

本文不对CppUnit源码做详细的介绍,而只是对CppUnit的应用作一些介绍。在本文中,您将看到:

      1、CppUnit源代码的各个组成部分。
      2、怎样设置你的开发环境以能够使用CppUnit。
      3、怎样为你的产品代码添加测试代码(实际上应该反过来,为测试代码添加产品代码。在TDD中,先有测试代码后有产品代码),并通过CppUnit来进行测试。

    本文叙述背景为:CppUnit1.9.0,Visual C++ 6.0,Windows2000。文中叙述有误之处,敬请批评指正。

    一、CppUnit源码组成

       CppUnit测试框架的源代码可以到 http://sourceforge.net/projects/cppunit/ 上下载。下载解压后,你将看到如下文件夹:


    图一

    主要的文件夹有:

    • doc: CppUnit的说明文档。另外,代码的根目录,还有三个说明文档,分别是INSTALL,INSTALL-unix,INSTALL-WIN32.txt。
    • examples: CpppUnit提供的例子,也是对CppUnit自身的测试,通过它可以学习如何使用CppUnit测试框架进行开发。
    • include: CppUnit头文件。
    • src: CppUnit源代码目录。

    二、初识CppUnit测试环境

      解压源代码包后,您一定急着想看看CppUnit到底是个什么样?Ok,下面我们就来揭开CppUnit的神秘面纱:

    1、进入example文件夹,用VC打开examples.dsw。我们先来看看CppUnit自带的测试例子。这些例子都是针对CppUnit自身的单元测试集,一方面这是CppUnit作者开发CppUnit框架过程中写的测试用例,另一方面,我们可以通过这些例子来学习如何在我们自己的工程中添加测试用例。

    2、将CppUnitTestApp工程设为Active Project(Win32 Debug),编译后运行,则可以看到CppUnit的基于GUI方式进行单元测试TestRunner的界面。点击“Run”,将会看到如图二所示界面:


    图二

    这是一个针对CppUnit的单元测试结果,它表明刚才我们做了11个测试,全部通过。
    点击“Browse”,我们还可以选择想要进行的单元测试,如图三:


    图三

       CppUnit将所有的单元测试按照树的结构来表示。在CppUnit中,最小的测试单元,称为TestMethod测试方法,而多个相关的测试方法又可以组成一个TestCase测试用例。多个测试用例又组成TestSuite测试包。测试包互相嵌套在一起,就形成了上面我们看到的树结构。我们可以选择其中任意的树节点来进行单元测试。

    3、将CppUnitTestMain工程设置为Active Project(Win32 Debug),编译并运行,我们来看看另一个单元测试的环境,如图四:


    图四

       这是一个基于文本方式的单元测试环境。CppUnit提供了几种测试环境,一种基于文本,一种基于GUI,即图三。

    4、将HostApp工程设置为Active Project(Win32 Debug),编译运行。如图五:


    图五

       这亦是一个对CppUnit自身进行的测试,只不过它向我们演示的是各种失败的测试。在基于GUI的测试环境中,若测试不成功,进度条显示红色,反之则为绿色。从测试结果我们可以看到失败的单元测试名称,引起测试不能通过的原因,以及测试失败的语句所在的文件及所在行数。

    三、CppUnit开发环境设置

      认识了CppUnit的测试环境,想必你已经是在磨拳擦掌,准备在你的开发过程中感受一下测试驱动开发的感觉了。不过,在使用CppUnit前,还需要设置一下你的开发环境。

    1、CppUnit的lib和dll
      CppUnit为我们提供了两套框架库,一个为静态的lib,一个为动态的dll。

    cppunit project:静态lib
    cppunit_dll project:动态dll和lib

      在开发中我们可以根据实际情况作出选择。进入src文件夹,打开CppUnitLibraries.dsw。分别编译这两个project,输出位置均为lib文件夹。
      另外一个需要关注的project是TestRunner,它输出一个dll,提供了一个基于GUI 方式的测试环境,即前面我们提到的两种测试环境之一。我们也需要编译这个project,输出位置亦为lib文件夹。
    为了方便开发,我们把这些编译出来的lib和dll(包括Debug版和Release版) copy 到我们自己建立的一个文件夹中(当然你也可以不这么做),例如F:/cppunit1.9.0/lib/,同时我们也把CppUnit源代码中include文件夹copy到我们自己的include文件夹下。然后在VC的tools/options/directories/include files和library files中设置include路径和lib路径。最后别忘了在你的project中link正确的lib。

    2、在你的VC project中打开RTTI开关。
      具体位置Project Settings/C++/C++ Language。

    3、为TestRunner.dll设置环境变量
      TestRunner.dll为我们提供了基于GUI的测试环境。为了让我们的测试程序能正确的调用它,TestRunner.dll必须位于你的测试程序的路径下。但最简单的方法是在操作系统的环境变量Path中添TestRunner.dll的路径,这样是最省事的。

    四、你的第一个TDD example

      一切准备就绪,现在我们可以来看看怎样添加测试代码了。前面我们提到过,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看看这几个宏的声明,本文在此不做详述。

    1、一个实现两个整数相加的类
      假定我们要实现一个类,类名暂且取做CPlus,它的功能主要是实现两个数相加(多简单的一个类啊,这也要测试吗?不要紧,我们只是了解怎样加入测试代码来测试它就行了,所以越简单越好)。 假定这个类要实现的相加的方法是:
    int Add(int nNum1,int nNum2); 
    Ok,那我们先来写测试这个方法的代码吧。TDD 可是先写测试代码,后写产品代码(CPlus)的哦!先写的测试代码往往是不能运行或编译的,我们的目标是在写好测试代码后写产品代码,使之编译通过,然后再进行重构。这就是Kent Beck说的“red/green/refactor”( 还记得基于GUI的测试环境的状态条吗?)。所以,上面的类名和方法应该还只是在你的心里,还只是你的idea而已。

    2、在VC中为测试代码建立一个 Project
      通常,测试代码和被测试对象是处于不同的Project中的。这样就不会让你的产品代码被测试代码所“污染 ”。
    在本例中,我们将建立一个基于GUI 方式的测试环境。在VC中,我们建立一个基于对话框的Project。别忘了link正确的lib,本例中我们使用静态的CppUnit lib。由于我们希望这个Project运行后显示的是图2这样的界面,所以我们需要在App的 Instance()中屏蔽掉原有的对话框,代之以CppUnit的GUI。
    CppUnit::MfcUi::TestRunner runner;
    runner.addTest(PlusTest::suite()); //添加测试
    runner.run(); //show UI
    /*
    CCPlusTestDlg dlg;
    m_pMainWnd = &dlg;
    int nResponse = dlg.DoModal();
    if (nResponse == IDOK)
    {
    	// TODO: Place code here to handle when the dialog is
    	// dismissed with OK
    }
    else if (nResponse == IDCANCEL)
    {
    	// TODO: Place code here to handle when the dialog is
    	// dismissed with Cancel
    }
    */
    
       前面我们提到过,TestRunner输出图2这样的对话框,这也是前面我们为什么要为TestRunner.dll的路径设置环境变量的原因。
    注意:PlusTest::suite()返回一个指向CppUnit::Test的指针.这个指针就是整个测试的起点。CppUnit::TestFactoryRegistry::getRegistry()根据TestSuite的名字返回TestFactoryRegistry工厂,然后调用工厂里的makeTest()对TestSuite进行组装,这是个递归调用,将建立起一个树状的测试结构。
    namespace PlusTest
    {
    	CppUnit::Test* suite()
    	{
    		CppUnit::TestFactoryRegistry ®istry = 
    			CppUnit::TestFactoryRegistry::getRegistry(plusSuiteName());
    		return registry.makeTest(); 
    	}
    }
    

    另外别忘加头文件:

    #include "CPlusTestSuite.h"
    #include <cppunit/ui/mfc/TestRunner.h>
    #include <cppunit/extensions/TestFactoryRegistry.h>
    3、在Project中加入一个类,取名CPlusTestCase
      CPlusTestCase从CppUnit::TestCase继承,代码如下:
    class CPlusTestCase : public CppUnit::TestCase
    {
    	CPPUNIT_TEST_SUITE(CPlusTestCase);
    	CPPUNIT_TEST(testAdd);
    	CPPUNIT_TEST_SUITE_END();
    public:
    	CPlusTestCase();
    	virtual ~CPlusTestCase();
    	void testAdd(); //测试方法
    }; 
    
    看到这几个宏了吗?它们可是在这大显身手了一把。
    CPPUNIT_TEST_SUITE(CPlusTestCase); 
    CPPUNIT_TEST( testAdd ); 
    CPPUNIT_TEST_SUITE_END(); 
    
      通过这几个宏,我们就把CPlusTestCase和testAdd注册到了测试列表当中。
    另外,我们需要在Cpp文件中加入另外一个宏:
    CPPUNIT_TEST_SUITE_NAMED_REGISTRATION(CPlusTestCase,PlusTest::plusSuiteName() ); 
      它将CPlusTestCase这个TestSuite注册到一个指定的TestFactory工厂中,这个TestSuite用 PlusTest::plusSuiteName()函数返回的名字来标识(前面介绍的suite()函数中就是通过这个名字来获取这个工厂的)。plusSuiteName()是PlusTest这个namespace下的一个函数,它返回我们为这个TestSuite建立的名字(本例我们取名为“plus”)。其实我们也可以不用这么做,直接在宏里写入“plus“即可。但是这样可以防止硬编码带来的麻烦。

    在测试类中,我们添加了一个测试方法:
    void testAdd(); 

    它测试的对象是前面提到的CPlus类的方法:

    int Add(int nNum1,int nNum2); 

    我们来看看它的实现:
    void CPlusTestCase::testAdd()
    {
    	CPlus plus;
    	int nResult = plus.Add(10,20); //执行Add操作
    	CPPUNIT_ASSERT_EQUAL(30,nResult); //检查结果是否等于30
    }         
      CPPUNIT_ASSERT_EQUAL是一个判断结果的宏。CppUnit中类似的其它宏请查阅TestAssert.h,本文在此不做详述 。
      另外,我们还可以覆写基类的 setUp()、tearDown()两个函数。这两个函数实际上是一个模板方法,在测试运行之前会调用setUp()以进行一些初始化的工作,测试结束之后又会调用tearDown()来做一些“善后工作” ,比如资源的回收等等。当然,你也可以不覆写这两个函数,因为它们在基类里定义成了空方法,而不是纯虚函数。另外,Cpp中要加入头文件:
    #include "plusSuite.h" 

    4、根据测试代码编写产品代码
      编写完上面的测试代码后,进行编译。编译肯定通不过,编译器会告诉我们CPlus类没有声明,因为我们还没有实现CPlus类呢!现在的工作就是马上实现CPlus类,让编译通过。现在你应该嗅到一点“测试驱动“的味道了吧?
      在VC中建立一个MFC Extension Dll的Project,在这个Project 中加入类CPlus,它的声明如下:

    class AFX_EXT_CLASS CPlus
    {
    public:
    	CPlus();
    	virtual ~CPlus(); public:
    	int Add(int nNum1,int nNum2);
    };        
    仅有一个方法,就是我们的测试代码要测试的那个方法。来看看它的实现:
    int CPlus::Add(int nNum1,int nNum2)
    {
    	return nNum1+nNum2;
    } 
      非常简单,不是吗?现在让前面那个包含测试代码的Project dependent这个Project,include 相关头文件,Rebuild All,你会发现编译已通过。你体会到了测试代码驱动产品代码了吗?当然我们的这个例子还很简单 ,没有重构这一步骤。
    运行我们的测试程序,你就会看到如图六的界面:


    图六

     

     

     

     

    单击”Browse”, 如图七:


    图七

      这下你应该对前面我们说的TestSuite的名字理解更深了吧。plus是一个测试包TestSuite,它的下面包含一个测试用例,这个测试用例下面又包含一个测试方法。   至此,我们对CppUnit测试框架的应用作了一个详细的介绍,希望能对你在进行TDD过程中有所帮助。 参考资料: CppUnit源码及说明文档 Website:http://tdd.nease.netEmail:cpluser@hotmail.comBlog:http://blog.csdn.net/cpluser/

     

    版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

    相关推荐


    什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
    单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
    动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
    适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
    策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
    设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
    模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
    迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
    外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
    单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
    组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
    装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
    观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
    代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
    工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
    状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
    命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
    备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
    顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
    享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结