开发者测试：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
