深入浅出单元测试

jokie

一　单元测试概述
    工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。
    其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。
    对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。多数讲述单元测试的文章都是以Java为例，本文以C++为例，后半部分所介绍的单元测试工具也只介绍C++单元测试工具。
    要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。
    一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试的所说的单元是指类。老纳认为，以类作为测试单位，复杂度高，可操作性较差，因此仍然应以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。
    有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，似乎有些道理。老纳认为，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。
    什么时候测试？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。老纳认为，不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。
    由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。
    关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的开发方式进行开发，先开发的代码先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。

二　测试代码编写
    下面该说说如果编写测试代码了，以一个例子来说明，开发环境是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、３、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都是非法输入，再如一个进行文件操作的函数，非法输入有这么几类：文件不存在；目录不存在；文件正在被其他程序打开；权限错误。
    如果函数使用了外部数据，则正常输入是肯定会有的，而边界输入和非法输入不是所有函数都有。一般情况下，即使没有设计文档，考虑以上三种输入也可以找出函数的基本功能点。实际上，单元测试与代码编写是“一体两面”的关系，编码时对上述三种输入都是必须考虑的，否则代码的键壮性就会成问题。