TDD 开发者测试:gtest 与 cctest

horance · December 31, 2020 · 36 hits

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());
}

误用

用户也需要关注TESTTEST_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

「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」,让帮助程序员更加快乐高效地编程!

No Reply at the moment.
You need to Sign in before reply, if you don't have an account, please Sign up first.