开发者测试：gtest与cctest

xUnit表示一组单元测试框架集合，其基本思想起源于SUnit。SUnit由极限编程之父Kent Beck使用SmallTalk设计实现。随后，Kent Beck与Erich Gamma结对编程实现了JUnit，这是一个Java实现的移植版本。

JUnit随着Java社区不断壮大，及其敏捷软件开发思潮的涌现，当前JUnit已经成为Java程序员最常使用的框架之一。当然，JUnit也在不断地演进，截止目前JUnit5已然面世，重焕青春。

JUnit之后，可谓百家争鸣。各个语言社区都诞生了自家优秀的xUnit实现，包括基于JVM实现的各种高级编程语言。它们基本继承或发扬了xUnit基本架构与方法论，部分后起之秀在用户界面友好性方面取得极大的改进和提升。例如，我所偏爱的Spock, ScalaTest框架。

在C/C++领域，xUnit框架也是百家争鸣，这里给大家介绍两款测试框架。

Google Test

Google Test使用C++语言实现，功能强大、系统稳定、移植性良好、支持自动发现，相对于C++社区其它xUnit实现，可谓技高一筹，在C++社区占据主导地位。

#include <gtest/gtest.h>
#include <stack>

namespace {
  struct StackSpec : testing::Test {
  private:
    void SetUp() override {
      s.push(1);
      s.push(2);
    }

  protected:
    std::stack<int> s;
  };
}

TEST_F(StackSpec, apply_pop_0_time) {
  ASSERT_EQ(2, s.top());
}

TEST_F(StackSpec, apply_pop_1_time) {
  s.pop();
  ASSERT_EQ(1, s.top());
}

TEST_F(StackSpec, apply_pop_2_time) {
  s.pop();
  s.pop();
  ASSERT_TRUE(s.empty());
}

但是，Google Test 也存在一些不尽人意的细节之处。

命名

用例名字必须遵循标识符的严格命名格则，否则编译不能通过。一方面，新增或修改用例时，输入长串下划线极度枯燥乏味；另一方面，极大地降低了用例的可读性。

当用例命名成为程序员的一种负担，其质量将大大折扣。但是，测试用例是系统行为描述最重要的“活文档”，它与被测系统的代码一并入库，并保持同步。如果，测试用例命名质量不高，"Test as Document"的愿景只能沦为痴人说梦了。

// Bad Smell: test cases must be named using c++ identifier.
TEST_F(RobotCleanerTest, at_beginning_the_robot_should_be_in_at_the_initial_position) {
  ASSERT_EQ(Position(0, 0, NORTH), robot.getPosition());
}

重复

RobotCleanerTest扮演测试装置，但与每个测试用例(TEST_F)分离实现，每个用例不得不一次次地重复RobotCleanerTest。

测试装置与测试用例相分离，破坏了它们之间的内聚性。当然，C++程序员忍受类与成员函数分离定义而引入的重复设计，早已司空见惯矣。一般地，在C++编译模型中，在头文件中定义类，实现文件中定义成员函数。但是，此处测试装置与测试用例往往都在同一个实现文件内，分离定义引入重复设计，无畏地给用户增加了不必要的负担。

// Bad Smell: you must duplicate fixture name for each test case.
struct RobotCleanerTest : testing::Test {
protected:
  RobotCleaner robot;
};
 
TEST_F(RobotCleanerTest, at_beginning_the_robot_should_be_in_at_the_initial_position) {
  ASSERT_EQ(Position(0, 0, NORTH), robot.getPosition());
}
 
TEST_F(RobotCleanerTest, robot_should_be_face_west_after_turn_left) {
  robot.turnLeft();
  ASSERT_EQ(Position(0, 0, WEST), robot.getPosition());
}

隐晦

测试装置与测试用例相分离，本应该被直观地理解为类与成员函数之间的关系。理论上，测试用例TEST_F与测试装置应该在同一个类域之中，TEST_F能够直接获取到测试装置的私有成员。例如，RobotCleanerTest::robot。

不幸的是，RobotCleanerTest与TEST_F存在隐晦的继承关系。如果用户不了解Google Test的实现机制，就根本无法理解成员变量RobotCleanerTest::robot为什么被声明为protected，而不是private。

struct RobotCleanerTest : testing::Test {
private: // should be protected
  RobotCleaner robot;
};
 
TEST_F(RobotCleanerTest, at_beginning_the_robot_should_be_in_at_the_initial_position) {
  // Error: 'RobotCleaner RobotCleanerTest::robot' is private within this context.
  ASSERT_EQ(Position(0, 0, NORTH), robot.getPosition());
}

误用

用户也需要关注TEST， TEST_F之间微妙的差异，并区分两者之间的使用场景，无疑增加了用户的心智包袱。例如，用户在此处本应使用TEST_F，而误用为TEST。这个例子较为幸运，编译器提示robot变量未定义，编译是失败的。但是，在特殊场景可能会逃出编译时检查，导致运行时用例失败。

struct RobotCleanerTest : testing::Test {
protected:
  RobotCleaner robot;
};

// should be TEST_F
TEST(RobotCleanerTest, at_beginning_the_robot_should_be_in_at_the_initial_position) {
  // Error: 'robot' was not declared in this scope.
  ASSERT_EQ(Position(0, 0, NORTH), @robot@.getPosition());
}

大小写

覆写Test::SetUp时，经常将其错误地写为setup, setUp, Setup，不经意地大小写错误可能导致运行时测试用例执行失败。当然，如果坚持使用override关键字，可以提高编译时安全性，将错误拦截至编译期。

struct RobotCleanerTest : testing::Test {
private:
  // Error: should override SetUp, not Setup/setup/setUp.
  void Setup() {
    robot.reset();
  }
 
protected:
  RobotCleaner robot;
};

cctest

cctest完成类似Google Test的基本功能特性。相对于Google Test，cctest定义了一套更人性化的DSL，改善用例描述的表达力。

使用字符串描述用例，改善用例的表达力；
在同一个类域内，使得测试用例与测试装置之间的关系更加内聚；
避免setup/setUp/SetUp大小写混用而引发错误。

#include "cctest/cctest.h"
#include <stack>

FIXTURE(StackSpec) {
  std::stack<int> v;   

  SETUP {
    v.push(1);
    v.push(2);
  }

  TEST("apply pop: 0 time") {
    ASSERT_EQ(2, v.top());
  }

  TEST("apply pop: 1 time") {
    v.pop();
    ASSERT_EQ(1, v.top());
  }

  TEST("apply pop: 2 times") {
    v.pop();
    v.pop();
    ASSERT_TRUE(v.empty());
  }
};

cctest的源码在Github上。

https://github.com/ccup/cctest