测试驱动开发（TDD）实践与技巧
文章目录
- 引言
-
- Google Mock
-
- 测试用例结构
- 断言
-
- 经典式断言
- Hamcrest 断言
- 测试驱动开发：第一个示例
-
- 开场白
- 开始吧
- 去掉不干净的代码
- 增量性
-
- fixture 设置
- 思索与测试驱动开发
- 测试驱动与测试
- 测试驱动开发基础与单元测试
-
- 单元测试的组织结构
- 测试驱动开发周期：红-绿-重构
- 测试驱动开发的思维
-
- 增量性
- 测试行为而非方法
- 使用测试来描述行为
- 保持简单
- 高质量测试
-
- FIRST，测试先行
-
- 快速
- 独立
- 可重复
- 自我验证
- 及时
- 一个测试一个断言
- 测试私有方法
- 不适合TDD的开发场景
-
- 1. 复杂算法
- 2. 物理边界
- 3. 难以构建测试的环境
- 关于TDD的研究
- TDD对我的影响
-
- 第一点：无论如何，重构之前先写测试
- 第二点：用单元测试来减少沟通成本
引言
测试驱动开发，英文全称 Test-Driven Development，简称 TDD，是一种不同于传统软件开发流程的开发方法。
在《程序员的职业素养》第五章，我第一次看到有关 TDD 内容，当时Bob大叔向我展示了一种不可思议的编程开发方法，这种方法颠覆了我的认知。Bob 大叔列举了 TDD 很多好处，例如确定性、降低代码缺陷、方便代码重构、测试单元文档化，更优秀的代码设计等等。并强力安利读者们尝试 TDD，因为 TDD 是专业人士的选择。
在 Bob 大叔的洗脑下，我决定去尝试学习如何使用 TDD。从写第一行 TDD 代码到现在，已经大概一年了，这期间我一直坚持用 TDD 的方式来写代码。还没毕业之前，需要写的代码比较少，鲜有机会锻炼 TDD 能力。进入公司工作后，就有大把的机会用 TDD 进行开发，对 TDD 的理解逐渐有一个比较全面的认知。此次要分享的目的就是向你展示实际使用 TDD 的系统方法，你将会学到：
- TDD的基本工作方式
- TDD的潜在好处
- TDD怎杨帮助解决设计缺陷
- TDD的难点和成本
- TDD怎么减少甚至免除调试工作
- 怎样长时间维持TDD
- 如何编写高质量的测试
另外，还会分享我这段时间使用 TDD 的一些感受，以及 TDD 对我开发思维的影响
Google Mock
在开始 TDD 之前，需要说明一些关于测试框架的内容，这一点不是必须的，你完全可以用assert来完成测试的工作，但是测试框架提供了更好编码体验，能够提高开发效率，你只需要花一点点的时间学习它，就能获得巨大的收获，何乐而不为呢。
本文所有的例子都是 C++ 代码，所用的测试框架为 Google Mock，它是一种模拟（Mock）和匹配器的框架，其中包含了单元测试工具 Google Test。
详细的安装以及使用，请参考 快速上手Google C++测试框架。这里我们简单重述一遍如何使用 Google Mock，以便你可以不被打断的继续看下去。
测试用例结构
一个测试用例，在 Google Mock 下，大致是这样的结构：
TEST(TestSuiteName, TestName)
{
... test body ...
}
TestSuiteName是测试套件名称，TestName测试用例名称。'测试套件’这个翻译很怪，让人不知所云，其实它是许多测试用例的集合，可以认为是一种逻辑上分组。
从左到右阅读测试套件和测试用例的名称，可以连成一句话，描述了我们想要验证的行为，例如下面的代码中：Set insert ignores duplicate values
TEST(SetInsert, IgnoresDuplicateValues)
{
std::set<int> a_set;
int val = 0;
a_set.insert(val);
a_set.insert(val);
ASSERT_THAT(a_set.size(), Eq(1));
}
断言
使用自动断言是自动化测试的关键，Google Mock 中提供了两种断言：
- ASSERT_* 失败是会终止当前函数，ASSERT_* 后面的代码将不会运行
- EXPECT_* 失败时不会终止，EXPECT_* 后面的代码将会继续运行
Google Mock 提供了两种形式的断言：经典式 和 Hamcrest 断言
经典式断言
下表列出了 经典式断言 的两个主要断言。其他框架也会使用类似的名称
| 形式 | 描述 | 实例 |
|---|---|---|
| ASSERT_TRUE(表达式) | 表达式返回假（或者0），测试失败 | ASSERT_TRUE(4<7) |
| ASSERT_EQ(期待值，实际值) | 期待值和实际值不等时，测试失败 | ASSERT_EQ(4, 20/5) |
更多关于经典断言的内容请参考：
- google test advanced
- google test primer
Hamcrest 断言
Hamcrest 断言是为了提高测试的表达能力，创建复杂断言的灵活性，以及测试错误所提供的信息
Hamcrest 断言使用匹配器比较实际结果。匹配器可以组成复杂但易懂的比较表达式。你也可以自己定义匹配器。
几个简单的示例胜过千言万语
TEST(StringTest, StringEq)
{
string actual = string("al") + "pha";
ASSERT_THAT(actual, Eq("alpha"));
}
断言可以从左到右读作：断定实际值等于"alpha"。对比与 ASSERT_EQ(actual, "alpha")，Hamcrest 断言用区区几个额外的字符就提高了阅读性。
匹配器的价值在于它能极大地提升测试的表达能力，许多匹配器能够减少所需的代码量，同时也能提升测试的抽象层次。
ASSERT_THAT(actual, StartsWith("alx"));
Hamcrest断言在提升失败信息的可读性方面意义更大。
Value of: actual
Expected: starts with "alx"
Actual: "alpha"
Hamcrest 断言真的很 Coooool，如果你想进一步了解它，可以参考 快速上手Google C++测试框架 中关于匹配器的部分。
关于 Google Mock 的部分，我们就此打住，了解了以上的内容，你已经可以无障碍继续阅读了。
太棒了！如果你坚持看到了这里，那么你已经穿好鞋，准备好向 TDD 出发了。相信我，这趟旅途一定会让你受益匪浅。
测试驱动开发：第一个示例
开场白
写个测试，保证它通过，接着重构设计。这就是TDD的全部内容。但是这个三个简单的步骤背后却另有乾坤。就像踢足球一样，规则简单，但是想要踢得好，就需要进行训练以及学习相应的技巧。为了让你更快的理解TDD，这里我举个例子，让我们一起用TDD的形式开发一个小工具。这个实例提供了很多教学点，展示了TDD如何增量地设计一个程序。
场景：字节转换器
我们需要一个类，它能将一组字节转换成一组音频采样点（float)，这样可以方便音频算法处理
再提供两个强假设：
- 字节都是以小端格式排列的
- 音频数据是 16 bit的，也就是说两个字节构成一个采样点(float)
开始吧
OK，让我们开始，上面的场景告诉我们，有一组字节(byte)，我们需要将其转换成采样点…。等等！我们应该从最简单的开始，如果这个字节数组只有两个字节呢？为此我们写个测试：
#include - 第一行代码包含了gmock的头文件
- 一个简单的测试声明需要使用 TEST 宏。TEST宏包括两个参数：测试套件名称和测试用例名称。从左右往右阅读测试套件和测试用例名称，可以连成一句话，描述了我们想要验证的行为：A Byte Converter converts two bytes to one float。
- 我们创建了一个
ByteConverter对象，然后…，停止！在写更多测试代码之前，我们已经加入了一些不能通过编译的代码：我们还没有定义ByteConverter类，先停下来解决这个问题。这个方法和TDD的三条规则保持一致：- 只在为了使失败的测试用例通过时才编写产品代码
- 当测试刚好失败时，停止继续编写。编译失败也是失败。
- 只编写刚好让一个失败测试用例通过的代码
我们现在编译失败了（原则二），因此我们停止编写测试，开始编写产品代码（原则一）。这种增量地获得反馈是很好的办法，因为有时候只需要几行代码，就能产生一大堆的编译错误。若能够及时的看到代码产生的错误，那么就可以更容易的解决它们。
编译器提示我们需要 ByteConverter 类。我们可以添加一对.h/.cpp文件，但是先别自找麻烦。相反，不要急于使用独立文件，先简单地在测试文件中包含所有东西。在最后提交代码的时候，或者苦于所有东西都放在同一个文件的时候，再以适当的方式把产品代码独立出去。这种方法可以减少一直在文件间来回切换的开销，是一种短期内不引入复杂开销而节省时间的方式。
#include 如果你无法忍受将测试代码和产品代码暂时放在一起的做法，那就马上把东西分散到不同的文件吧，依然可以继续我们的示例。但是我建议你先试试这种方法，因为它可能是一种更有效的工作方式。
我们遵循了原则三：只编写刚好让测试通过的代码。很显然，我们并没有完成测试，ConvertTwoBytesToFloat没有测试任何行为，所以它验证不了什么，但是我们却对负反馈（编译失败）采取了应对措施，加入了足够的代码消除它。
构建并运行上面的测试就能得到正反馈了，如下：
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from AByteConverter
[ RUN ] AByteConverter.ConvertTwoBytesToOneFloat
[ OK ] AByteConverter.ConvertTwoBytesToOneFloat (0 ms)
[----------] 1 test from AByteConverter (0 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (0 ms total)
[ PASSED ] 1 test.
测试通过，欢乐时刻！虽然这个测试除了创建一个空类之外，没有干任何事情。但是，我们已经有了一些基本要素。并且，我们已经验证目前代码是正确的。如果你include的头文件写错了，或者class定义的分号忘记加了，那么你将第一时间发现这些错误。所以要尽早并频繁地测试，通常测试失败的原因只有一个。
继续吧！往测试中加入几行代码，来表示我们预期的客户端与ByteConverter对象交互方式
#include 如上述代码所示，我们暴露了一个convertTwoBytesToFloat公共函数。尝试编译会失败，因为convertTwoBytesToFloat不存在。这个负反馈迫使我们去编写足够的代码，让测试通过编译。
class ByteConverter
{
public:
float convertTwoBytesToFloat(uint8_t byte_1st, uint8_t byte_2nd)
{
return 0.0f;
}
};
现在代码可以编译了，所有测试也通过了。是时候验证一些东西了：给定两个字节，convertTwoBytesToFloat 能够正确一个float返回吗？我们加入一个验证结果的断言：
TEST(AByteConverter, ConvertTwoBytesToOneFloat)
{
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
float result = converter.convertTwoBytesToFloat(two_bytes[0], two_bytes[1]);
ASSERT_THAT(resutl, ::testing::FloatEq(1.0));
}
断言可以用来验证结果是否符合预期。上面代码中断言中声明了convertTwoBytesToFloat返回的值等于1.0。现在编译通过了，但是断言却失败了。
乍一看，Google Mock给出的信息可能不太容易读懂。从最后一行开始看，它提示我们有一个测试没有通过，并且在 [RUN] 和 [FAILED] 之间信息帮助我们了解测试为什么失败。在上面的例子中，可以看到下面信息：
Value of: result
Expected: is approximately 1
Actual: 0 (of type float)
断言信息非常明确：Google Mock期待 result 的值应该约等于1，但实际上却是0.
断言是意料之中的，因为为了通过编译，我们特意硬编码了一个0。得到这个负反馈是好事，也是TDD周期中可以发生的事情。首先，我们保证新加的测试不能通过，这表示这个功能没有被显示（有时候是通过的，但这通常不是个好事）。起初测试是失败，在加入适当的代码后测试通过了，这也说明测试时可靠的。
失败的断言提醒我们编写仅通过断言的代码即可。如下：
class ByteConverter
{
public:
float convertTwoBytesToFloat(uint8_t byte_1st, uint8_t byte_2nd)
{
int16_t result = byte_2nd | byte_1st;
return (float)(result);
}
};
现在编译并运行。最后两行显示测试通过了：
去掉不干净的代码
啥？我们才写了两行产品代码和四行测试代码就有问题？当然，区区几行代码也容易引入缺陷。让我们先审阅一下刚写的代码，找一找缺陷吧。有一点是确定的，测试中的断言不是非常便于阅读。
ASSERT_THAT(result, ::testing::FloatEq(1.0));
我们希望断言阅读起来想个句子，但是::testing::却妨碍了阅读。我们引入using来帮忙：
#include 现在断言看起来好多了，我们称这个小小的改动为重构，在不改变现有行为的前提下改进了设计。
另外，byte_2nd | byte_1st 看起来不知所云，还有(float)(result)强制转换不是良好的编程风格，我们进一步重构：
class ByteConverter
{
public:
float convertTwoBytesToFloat(uint8_t byte_1st, uint8_t byte_2nd)
{
return static_cast<float>(convertTwoBytesToInt16(byte_1st, byte_2nd));
}
private:
int16_t convertTwoBytesToInt16(uint8_t byte_1st, uint8_t byte_2nd)
{
return byte_2nd | byte_1st;
}
};
我们使用static_cast替换了强制转换，并封装convertTwoBytesToInt16用来提高了代码的可阅读性。
现在看起来好多了，重新编译并且运行，保证测试时通过。
增量性
我们已经完成了将两个比特转换成浮点数值的函数，如果了解过音频的同学可能注意到了，我们编写的代码不符合音频处理的使用习惯，因为音频处理中，采样点的范围应该是[-1, 1]。就目前来说，我们的代码中没有做归一化，所以它并不符合规范。所以数值的归一化是我们接下去要做的事情。
为了测试新的行为，我们需要写一个新的单元测试：
TEST(AByteConverter, ConvertTwoBytesToNormalizedFloat)
{
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
float normalized_result = converter.convertTwoBytesToNormalizedFloat(two_bytes[0], two_bytes[1]);
}
同样的，convertTwoBytesToNormalizedFloat 没有定义，所以编译不过。因此编写刚好让编译通过的代码：
float convertTwoBytesToNormalizedFloat(uint8_t byte_1st, uint8_t byte_2nd)
{
return 0.0f;
}
然后编写断言：
TEST(AByteConverter, ConvertTwoBytesToNormalizedFloat)
{
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
float normalized_result = converter.convertTwoBytesToNormalizedFloat(two_bytes[0], two_bytes[1]);
ASSERT_THAT(normalized_result, FloatEq(1.0/32768));
}
断言失败，这是预期之中的。接下去，写刚好让测试通过的代码：
float convertTwoBytesToNormalizedFloat(uint8_t byte_1st, uint8_t byte_2nd)
{
return convertTwoBytesToFloat(byte_1st, byte_2nd)/32768.0f;
}
新的测试通过了！但是代码中去出现了一些坏味：32768这个数字不知所云，并且重复了两次，一次在测试之中，一次在产品代码中。该进行重构了：
class ByteConverter
{
public:
constexpr static float MAX_16BIT_VAL = 32768.0f;
float convertTwoBytesToNormalizedFloat(uint8_t byte_1st, uint8_t byte_2nd)
{
return convertTwoBytesToFloat(byte_1st, byte_2nd)/MAX_16BIT_VAL;
}
...
};
TEST(AByteConverter, ConvertTwoBytesToNormalizedFloat)
{
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
float normalized_result = converter.convertTwoBytesToNormalizedFloat(two_bytes[0], two_bytes[1]);
ASSERT_THAT(normalized_result, FloatEq(1.0/ByteConverter::MAX_16BIT_VAL));
}
我们将32768提取为静态常量，消除了硬编码的重复，并且提供了代码的可阅读性。
fixture 设置
在重构的时候，不仅要审阅产品代码，还要审阅测试代码。如上所述，我们的测试都要创建 ByteConverter 实例，并且使用相同的代码。我们不乐意看到这种貌似无关紧要的重复代码。这些重复会积累的很快，并且通常会演化为更为复杂的重复代码。这也会让测试变得主次不分，对于阅读代码的来说，这会分散注意力，从而忽视了真正需要关注的内容。
相关的测试拥有一些共同的代码是常见的，Google Mock 允许我们定义一个 fixture 类，我们可以在这个类里为相关的测试声明函数和数据。
class AByteConverter : public Test
{
public:
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
};
TEST_F(AByteConverter, ConvertTwoBytesToFloat)
{
float result = converter.convertTwoBytesToFloat(two_bytes[0], two_bytes[1]);
ASSERT_THAT(result, FloatEq(1.0));
}
TEST_F(AByteConverter, ConvertTwoBytesToNormalizedFloat)
{
float normalized_result = converter.convertTwoBytesToNormalizedFloat(two_bytes[0], two_bytes[1]);
ASSERT_THAT(normalized_result, FloatEq(1.0/ByteConverter::MAX_16BIT_VAL));
}
上述代码中，我们创建了一个名为 AByteConverter 的 fixture（必须继承::testing::Test)。在 fixture 内部我们声明了公共变量 converter 和 two_bytes，以便测试可以访问。
Google Mock 运行每个单元测试时，会创建fixture实例。也就是说，在运行 ConvertTwoBytesToFloat 之前，它会创建一个 AByteConverter 实例。在运行ConvertTwoBytesToNormalizedFloat之前，创建另一个 AByteConverter 实例。
为了使用fixture，我们将宏TEST改成了TEST_F，F表示fixture。如果忘记加F，所有测试都会失败。
去除掉重复的测试代码至少了两个好处：
- 提高了测试的抽象度。现在每个测试只有两行代码，这有助我们集中精力关注与测试相关的东西
- 可以减低未来的维护测试的开销。试想一下，如果
ByteConverter的构造函数发生变化，那么只需要改动一个地方即可。
思索与测试驱动开发
简单的说，TDD的周期就是写一个测试，先确保测试失败，然后编码让其通过，接着审阅代码和打磨设计（包括测试的设计），最后保证所有测试仍然通过。在一天中，你不断的重复这个周期，保持周期尽量小，以便得到更多的反馈。
让我们继续下一个测试，我们传入一组字节，得到一组浮点值。沿着这个思路想下去，我们首先会考虑，返回的个数是多少？Ok，为了验证这个行为，让我们来写一个测试：
TEST_F(AByteConverter, ConvertsBytesToFloatsWithSizeOfHalfSizeOfBytes)
{
int num_bytes = 5;
std::vector<uint8_t> five_bytes(num_bytes);
auto floats = converter.convertBytesToFloat(five_bytes);
}
我们编写了一个新的函数convertBytesToFloat，它返回一组浮点数。同样的，这里提示编译失败，写一个刚好让编译通过的代码：
std::vector<float> convertBytesToFloat(const std::vector<uint8_t>& bytes)
{
return std::vector<float>();
}
编译通过，接着写测试代码：
TEST_F(AByteConverter, ConvertsBytesToFloatsWithSizeOfHalfSizeOfBytes)
{
int num_bytes = 5;
std::vector<uint8_t> five_bytes(num_bytes);
auto floats = converter.convertBytesToFloat(five_bytes);
ASSERT_THAT(floats.size(), Eq(num_bytes/2));
}
测试失败。然后接着写产品代码：
std::vector<float> convertBytesToFloat(const std::vector<uint8_t>& bytes)
{
auto num_floats = (bytes.size() / 2);
std::vector<float> floats(num_floats);
return floats;
}
在编译运行，测试通过。值得庆幸的是，上面的代码没有需要重构的地方，至少现在没有。所以我们赶紧进入下一个测试。
很自然的，下一个测试中我们应该验证其转换的浮点值是否正确：
TEST_F(AByteConverter, ConvertsBytesToFloats)
{
std::vector<uint8_t> five_bytes{
0x01, 0x00, // 1
0x02, 0x00, // 2
0x00
};
auto floats = converter.convertBytesToFloats(five_bytes);
ASSERT_THAT(floats[0], Eq(1));
ASSERT_THAT(floats[0], Eq(2));
}
很明显，测试失败了：
非常好，这是符合预期的失败，我们接着写让测试刚好通过产品代码：
std::vector<float> convertBytesToFloats(const std::vector<uint8_t> &bytes)
{
auto num_floats = (bytes.size() / 2);
std::vector<float> floats(num_floats);
for(int i = 0; i < num_floats; ++i)
{
floats[i] = convertTwoBytesToFloat(bytes[i*2], bytes[i*2 + 1]);
}
return floats;
}
接着编译运行，所有测试都通过了。
重构时间到！现在的代码中有好几处可以进行改进：
convertBytesToFloats函数中，2多次出现，并且含义不明确- 新的测试代码中，用了两个
ASSERT_THAT来验证结果。但是如果返回的数组包含多个值呢？岂不是要写一大串的ASSERT_THAT才能验证结果？其实我们只需要一个ASSSERT_THAT就可以对比容器的内容了 five_bytes变量在两个单元测试中都出现了，可以通过fixture来消除重复
先从最简单的重构开始，消除重复的five_bytes
class AByteConverter : public ::testing::Test
{
public:
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
std::vector<uint8_t> five_bytes
{
0x01, 0x00, // 1
0x02, 0x00, // 2
0x00
};
};
TEST_F(AByteConverter, ConvertsBytesToFloatsWithSizeOfHalfSizeOfBytes)
{
auto floats = converter.convertBytesToFloats(five_bytes);
ASSERT_THAT(floats.size(), Eq(five_bytes.size()/2));
}
TEST_F(AByteConverter, ConvertsBytesToFloats)
{
auto floats = converter.convertBytesToFloats(five_bytes);
ASSERT_THAT(floats[0], Eq(1));
ASSERT_THAT(floats[1], Eq(2));
}
记得每次重构完成后都要重新运行单元测试，确保重构没有改变代码行为。
然后消除多余的ASSERT_THAT，只需要添加一个匹配器
class AByteConverter : public ::testing::Test
{
public:
ByteConverter converter;
std::vector<uint8_t> two_bytes{0x01, 0x00}; // 1.0
std::vector<uint8_t> five_bytes
{
0x01, 0x00, // 1
0x02, 0x00, // 2
0x00
};
std::vector<float> floats_of_five_bytes
{
1.0f,
2.0f
};
};
TEST_F(AByteConverter, ConvertsBytesToFloats)
{
auto floats = converter.convertBytesToFloats(five_bytes);
ASSERT_THAT(floats, ContainerEq(floats_of_five_bytes));
}
我们引入了ContainerEq匹配器，它可以比较容器的内容。更多关于匹配器的内容，参考Matchers
另外，为了精简测试代码，我们将要验证的结果floats_of_five_bytes加入到fixture中。
最后，给予2一个有意义的名字：
class ByteConverter
{
public:
constexpr static float MAX_16BIT_VAL = 32768.0f;
constexpr static size_t NUM_BYTES_OF_16BIT = 2;
...
std::vector<float> convertBytesToFloats(const std::vector<uint8_t> &bytes)
{
auto num_floats = (bytes.size() / NUM_BYTES_OF_16BIT);
std::vector<float> floats(num_floats);
for(int i = 0; i < num_floats; ++i)
{
floats[i] = convertTwoBytesToFloat(bytes[i*NUM_BYTES_OF_16BIT], bytes[i*NUM_BYTES_OF_16BIT + 1]);
}
return floats;
}
测试驱动与测试
或许有人觉得我们的测试用的数据都太弱了，应该增强测试数据，并增加新的测试来保证结果是正确的，例如编写多组长度不同的bytes，然后进行测试。
TDD诞生初期有个口头禅：“可能出现问题的地方才需要测试”。我们写的字节转换器出现问题的风险比较小，即使不挨个测试一遍，应该也不会出什么问题。
另一个相反的观点是，什么都可能出现问题，无论它多简单。这种观点下，我们可能需要提供一份上百个断言的测试用例，测试可能出错的每一种情况。但是它确实提升了我们发布代码的信心。
那么正确答案是什么？考量的重点在于我们在做测试驱动开发，而非测试。你或许会问：这两者有什么区别吗？答案是肯定。用测试的技巧，你会全面的分析，并创建大量的测试来罗列不同的行为。TDD则着力于代码设计，测试主要用于描述你要构建的行为，这些测试大都是TDD流程的附属产物，有了这些测试，在接下来改动代码的时候，你将更有信心。
TDD与测试区别很微妙。TDD的一个重要方面就是秉承够用心态。你写的测试只是为了开发代码做准备的。当要开发下一个行为时，再写测试。如果代码逻辑一样，就可以不写测试了。
既然选择了TDD，那么来完成接下来一个测试吧，让结果归一化，但是在这之前，先判断下返回数组的大小：
TEST_F(AByteConverter, ConvertsBytesToNormalizedFloatsWithSizeOfHalfSizeOfBytes)
{
auto normalized_floats = converter.convertBytesToNormalizedFloats(five_bytes);
}
convertBytesToNormalizedFloats未定义，编译不过。因此编写刚好让编译通过的代码：
class ByteConverter
{
public:
...
std::vector<float> convertBytesToNormalizedFloats(const std::vector<uint8_t>& bytes)
{
return std::vector<float>();
}
...
};
接着写断言，用于验证行为：
TEST_F(AByteConverter, ConvertsBytesToNormalizedFloatsWithSizeOfHalfSizeOfBytes)
{
auto normalized_floats = converter.convertBytesToNormalizedFloats(five_bytes);
ASSERT_THAT(normalized_floats.size(), Eq(five_bytes.size()/2));
}
毫不意外测试失败了。因此接下来写一个刚好让测试通过的产品代码
std::vector<float> convertBytesToNormalizedFloats(const std::vector<uint8_t>& bytes)
{
return convertBytesToFloats(bytes);
}
这里我们之间调用convertBytesToFloats就可以了。虽然它并没有归一化浮点数，但是返回结果的大小是我们想要的。
编译运行，测试通过！散花~
最后一个测试，让验证归一化的结果：
class AByteConverter : public ::testing::Test
{
public:
...
std::vector<float> norm_floats_of_five_bytes
{
1.0f/ByteConverter::MAX_16BIT_VAL,
2.0f/ByteConverter::MAX_16BIT_VAL
};
};
TEST_F(AByteConverter, ConvertsBytesToNormalizedFloats)
{
auto normalized_floats = converter.convertBytesToNormalizedFloats(five_bytes);
ASSERT_THAT(normalized_floats, ContainerEq(norm_floats_of_five_bytes));
}
编译并运行，断言失败
Value of: normalized_floats
Expected: equals { 3.05176e-05, 6.10352e-05 }
Actual: { 1, 2 }, which has these unexpected elements: 1, 2,
and doesn't have these expected elements: 3.05176e-05, 6.10352e-05
因此接着写让测试通过的代码：
std::vector<float> convertBytesToNormalizedFloats(const std::vector<uint8_t>& bytes)
{
auto normalized_floats = convertBytesToFloats(bytes);
std::transform(normalized_floats.begin(), normalized_floats.end(),
normalized_floats.begin(),
[](float x){return x/MAX_16BIT_VAL;}
);
return normalized_floats;
}
编译运行测试，太棒了，所有测试都通过了。
就这样我们增量性的完成了一个简易版字节转换器，它已经可以满足一些需求了，例如帮助解码16 bit的wav文件。如果你只有16bit的wav要解码，它完全就够了。当然，它可以继续扩展，例如可以支持8bit、32bit，可以支持多通道解码等等。这些新的需求都可以用TDD很好的完成。
这个方案绝对不是唯一或者最好的，但是我们已经有足够的信心去发布了，这才是最重要的。最后要做的事情就是将ByteConverter代码从测试代码中剥离，放到单独的 .h/.cpp 中，然后提交代码。
下面是完整的代码：
// byte_converter.h
#pragma once
#include // byte_converter_test.cpp
#include "byte_converter.h"
#include 测试驱动开发基础与单元测试
单元测试的组织结构
TDD会产出单元测试。了解如何组织测试有助于你写出更容易被人理解的单元测试。
测试都有相同的流程。首先先设置好合适的条件，然后执行代表要验证的行为的代码，最后验证结果是否和预期一样（有些测试可能要做一些清理工作，例如关闭之前打开的数据库连接）
通常测试的基本构成包括：测试初始化（Arrage)、测试的行为（Act）以及怎样验证结果（Assert）。Arrange、Act 和 Assert（AAA，三A），它能提醒你直观地去组织测试以便快速阅读。
有一个3A类似的助记词：Given-When-Then。即给定(Given)一个上下文、当(When)测试调用一些行为，然后(Then)验证结果。举个例子：
TEST(ASet, IsNoLongerEmpterAfterElementInserted)
{
// Given
std::set<int> a_set;
int val = 0;
// When
a_set.insert(val);
// Then
ASSERT_FALSE(a_set.empty());
}
如果测试用例中所有的测试都需要一条或者更多的相同初始化代码，那么可以将它们写在 fixture 的初始化函数中。在 Google Mock 中，这个函数必须叫 SetUp（覆写了基类的虚函数）。例如：
class ASet : public Test
{
public:
void SetUp() override
{
a_set.insert(val);
}
std::set<int> a_set;
int val = 0;
};
TEST_F(ASet, IsNoLongerEmpterAfterElementInserted)
{
ASSERT_FALSE(a_set.empty());
}
TEST_F(ASet, HasSizeOfOneAfterElementInserted)
{
ASSERT_THAT(a_set.size(), Eq(1));
}
与之类似的，如果有相同的清理工作（关闭数据库连接、释放内存等等），可以覆写 TearDown。
测试驱动开发周期：红-绿-重构
在做测试开发的时候，要重复一下简短的周期：
- 写一个测试（红）
- 让测试通过（绿）
- 优化设计（重构）
将TDD周期记在脑海里，可以让你习惯两件事情。第一，你需要写一个测试说明代码行为。第二，每个周期都要清理代码。养成这个习惯会使你思想得到解放，进而去思考增量开发中更具有挑战的问题。
另外，一定要恪守TDD开发周期，这能让你集中精力：在红阶段，着力于系统行为的描述；在绿阶段，要重点关注如何快速实现功能；在重构阶段，关心如何提高代码的质量。不能遵守TDD的开发周期会让你开发变得更慢。
测试驱动开发的思维
持有正确的实践心态是成功运用TDD的基础，下面是一些运用TDD时有效的思维方式
增量性
TDD以渐进的方式从无到有的开发一个功能完善的系统。TDD支持类似增量思维的小步方法。你可以逐个地处理单元测试，使用测试来定义和验证它们的行为，在任何时间点你都可以停止开发，并且知道你已经构建了测试所描述的系统的行为。我们可以认为，任何没有测试描述的行为都没有实现，而经测试描述的行为则正确且完整地实现了。
此外，用单元测试作为项目进度的衡量单位，帮助你更快的进入到编码的状态中去。当你正在开发一个功能时，却因为紧急的事情被突然打断，等你处理完紧急事情回到键盘前准备继续时，这时候你通常要花不少时间来回忆我刚才开发到哪了？如果你遵循TDD的开发思维，以增量的形式逐个处理单元测试，那么你可以通过单元测试的状态立马进入编码状态。
测试行为而非方法
TDD初学者常会放一个错就是集中精力去测试成员函数。“我们实现了一个Add方法，那么再写一个TEST(AClassCollection, Add)的测试”。Add虽然只是一个方法，但它却可能有多中不同的行为，比如 Add 增加了size、Add之后容器不再为空，再或者Add会忽略重复的数据。如果你将这些行为的验证都塞进一个单元测试中，此时，测试就没有文档价值了，同时，理解一个测试要花费的时间也会增加。
相反的，你应该把注意力放在代码行为上。如果加入一个重复的数据会怎样？如果客户传入一个空的数据呢？如果数据是无效的呢？我们就这几个考量做下面几个独立的测试：
TEST(AClassCollection,IgnoresDuplicateElementAdded);
TEST(AClassCollection,UsesDefalutElementWhenEmptyElementAdded);
TEST(AClassCollection,ThrowsExceptionWhenElementNotValidAdded);
使用测试来描述行为
你可以把测试想象成一个示例，用它来描述或者文档化系统中的行为。你可以通过两个方面来理解一个编写良好的测试。第一，测试名称，它概括了特定上下文中系统表现出的行为。第二，测试语句本身，它精炼的展示了一个测试行为。
越是重视TDD的文档功能，越懂得高质量测试的重要性。测试的文档性功能时TDD的附属产物，为了保证在单元测试中的投入能得到良好的回报，必须保证其他人能够很容易的理解单元测试，否则你的单元测试就是在浪费别人的时间。
良好的测试可以通过全面记录系统的行为来节约时间。只要所有测试都通过，那么它就能准确传达系统的行为，也不会过时。
保持简单
当你写一个新的测试，来验证系统行为时，首先应该用你能想到最简单最粗暴的方式来实现这个功能。直到这个简单的方案无法满足新的需求时，再采用另一个稍微更复杂一点的方案来满足需求。
在实际的开发工程中，每次迭代都会交付新特性，其中一些你可能从未考虑过。如果系统不能保持简单，那么这种突如其来的特性可能会让你苦不堪言。为此，最好的防范方法就是保持简单的设计：代码易读、没有冗余、没有所谓的复杂性。具有这些特性可以大大减少维护成本。
高质量测试
FIRST，测试先行
想知道如何写出高质量的测试吗？可以对照 FIRST 原则：
- F，快速（Fast）
- I，独立（Isolated）
- R，可重复（Repeatable）
- S，自我验证（Self-verifing)
- T，及时（Timely）
快速
保持TDD的周期尽量短非常重要。如果测试需要三四秒来编译、链接和运行测试的话，你可以在短时间内获得很多反馈。但试想一下，如果测试集需要两分钟来构建和运行，你会多久运行一次呢？或许十分钟。那如果运行测试集需要20分钟呢？恐怕你一天只会运行几遍
如果没有快速的反馈，你编写的测试会变少，代码重构会更少，从引入问题到发现问题的间隔也会变得更长。因此高质量的测试必须是快速的。有哪些因素会影响测试的速度呢？
第一、构建的开销。C++系统的构建时间是个很大的开销。一些大系统编译、链接的时间需要好几分钟，有时候要更长。大部分构建时间与代码的依赖直接相关。依赖于改动的代码必须重新编译。
如果一个类暴露了大量的接口，那么接口发生变化时必须重新编译使用此类的客户端。或许可以考虑使用 “pointer to implementation”，PIMPL 惯用法。这样就可以随心所欲地修改和创建新的函数了，而不用重新编译公开的接口。
第二、对协作者的依赖。如果测试代码和另一类交互，且这个类调用了外部API（如一个数据库调用），那么必须等待API调用完成。花费几毫秒建立数据库连接，然后执行一次操作，似乎不太会浪费时间。但是如果有成千上万个测试都有这样的开销，那么就要花费数分钟才能运行完所有测试。
因此，应该在单元测试中避免调用外部API，这包括：数据库服务、Web服务、文件的IO等等。这些都会导致你的测试运行速度变慢，关于外部API的测试，应该被归为集成测试，而非单元测试。
有时候你可以只运行测试的集子来加速测试的运行时间。大部分单元测试的工具运行运行整个测试中的一个子集。此外，很多 IDE 提供了更为方便的操作，例如 Clion 中，可以单独运行一个 fixture 或者一个单元测试：
虽然运行测试的子集可以节省时间，但是请记住，运行的测试越少，今后发现问题就会越多，进而也需要更多的时间来修复。
独立
测试应该是独立，只会因为一个原因失败。测试间是彼此独立的，使用静态数据或者全局数据的测试可能会因为旧的数据而失败。
应尽量避免在测试中引入静态数据或全局数据，如果不得已需要这么做，那么应该在测试收尾阶段(TearDown）恢复数据。
可重复
高质量的测试是可重复的，一遍一遍的运行得到的结果总是相同的。
下列原因可能导致测试间隙性失败：
- 静态数据。好的测试不会受到其他测试的影响，如果静态数据可能会使测试失败，那么你在加入或者移除一些测试时，才会看到真正的失败
- 不稳定的外部服务。有些测试依赖于你无法控制因素，例如系统时间、文件系统，数据库等。可以引入测试替身（Mock）来打破这种依赖。
- 程序并发。多线程技术会导致一些不确定的行为，这对单元测试而言是极大的挑战。
自我验证
所谓自我验证就是采用自动化测试，而非手动测试。每个单元测试至少有一个断言，利用断言来完成自动化测试。不要在测试中加入 cout 或者日志来代替断言。
及时
及时编写测试意味着你要先写测试。同样，不要一开始写写一堆测试。相反，每次只写一个测试，甚至在每个测试中只加入一个断言。
也许你会有这样的疑问：在代码完成后写测试和代码完成前写，到底有什么区别？
说实话，如果你是一个没有感情的写代码机器，这两者并没有区别。但由于人为的原因，就产生了区别。首先，一旦写好代码，大多数程序员就认为完成了“真正”的工作。他们自信满满地认为能写出正确的代码，经常满足于一两个简单的手动测试。因此，他们对为写一些测试来证明他们已经知道的东西并不感兴趣。并且，他们也会认为代码编码写得足够好了，于是就很少利用测试整理代码。第二，日程安排压力通常会其主导作用，代码编写完后的事情只会得到短暂的关注。
一个测试一个断言
遵循一个简单的小方法就可以让你测试质量得到提升：尽量保持一个测试一个断言。
测试名称是代码行为的描述，一个测试如果涵盖多个行为，测试名称就不能准确的描述系统行为，并且为了验证多个行为，你通常会写多个断言。
多个断言会将多个行为揉进一个测试，这导致阅读测试的人需要花费更多的时间来理解测试。另一种让人头疼情况是，一个行为出现在多个测试中，当这个行为发生变化时，你需要改动多处，这必然增加了我们重构的成本。
要尽量保持一个测试一个断言。有时候多个断言也是合理的，例如在验证一大堆数据时引入多个断言（对结构体各个成员的判定）
测试私有方法
我们是否要测试私有方法？大多数情况不需要。如果你发现一定要测试私有接口才能及时获得反馈，那么首先请思考下是否能将这些私有接口进行拆分，举个例子，有个相当复杂的类，只有一个公共接口：
class AComplexClass
{
public:
void fun();
private:
void A_fun0();
void A_fun1();
void A_fun2();
void B_fun0();
void B_fun1();
void B_fun2();
};
我们可以将它进行拆分，然后分别对拆分后的类进行测试即可
class AComplexClass
{
public:
void fun();
private:
A a_;
B b_;
};
class A
{
public:
void fun0();
void fun1();
void fun2();
};
class B
{
public:
void fun0();
void fun1();
void fun2();
};
如果拆分也不管有，并且这个私有接口真的困扰了你，那么不要纠结了，把这个接口公有化然后进行测试吧。虽然这破坏了一点点的信息隐蔽的原则，但是我们只是暴露了一个接口，并不是将所有接口公开，这并不会引起太多的麻烦。
不适合TDD的开发场景
TDD的开发方式很棒，它适合大多数的开发场景，但是有些情况，TDD就显得无能无力了。下面为大家总结一些不适用TDD的情况
1. 复杂算法
曾经有人尝试用TDD开发数独算法，但是失败了。数独的玩法非常简单，可以说需求非常明确：在每个空格子上添上一个合适的数字，让它在每行、每列、每个粗线宫都不重复就可以了。但这个看似简单的需求，实现起来却非常困难。
TDD 开发的前提是：我知道这种方法如何工作。如果不知道这个方法如何工作，就无法用TDD去实现它。
因此在开发复杂算法时，首先应该搞清楚算法的原理，当你对算法流程、算法实现都胸有成竹的时候，再考虑用TDD去开发它。
阻碍TDD在开发算法上大展身手的另一个原因是，一些复杂算法的结果难以验证。
举个例子，你现在要开发一个傅里叶变化的模块，输入一些数据，得到傅里叶变换的结果。你花了一些时间，看懂了傅里叶变化的公式，对其实现也有把握，但是在写断言的时候就发现结果的验证太困难了，你可能需要借助matlab或者python来预先得到结果，然后复制结果到断言中。
ok，至少还有matlab和python可以帮助你。但如果连matalb或者python都没有相应的算法模块呢？那么你应该如何验证算法结果？手算吗？我的天哪。
算法模块之间的依赖性会导致另一个棘手的问题：测试依赖性。想象一个算法由好几个模块组成，模块有底层算法，也有上层应用，层层依赖：A <- B <- C。在这里 A 为底层模块，B 依赖于 A，C 又依赖于 B。
如果某一天 A 模块算法输出的结果发生了变化，那么不仅 A 模块的测试要做修改，另外所有直接或者间接依赖于 A 的模块测试都要做修改。
此外，数据驱动的算法也无法用TDD来开发，例如机器学习、深度学习。因为其结果与数据相关，当数据发生变化时，算法行为也会发生变化，这就没法写测试用例了。
2. 物理边界
在开发一些与物理现实世界交互的代码时，TDD似乎不起作用。
例如，假设你被安排写一个控制铃声的程序，当某些事件发生时，程序必须响铃。那么如何测试”响铃“？在自动测试领域，这是个相当困难的问题。但是如果在手动测试领域，你只需要自己触发事件，然后听是否正常响铃就完事了。目前，软件控制着与物理世界的部分让自动化测试显得那么的不切实际，以至于手动测试才是最佳选择。
与GUI相关的内容也不适合TDD，例如前端。可以用MVC等模式将表现层和逻辑层分开，可以对 M 和 C 做TDD，而放任 V，因为view部分的代码测试环境非常难搭，另外，大多数情况都不需要通过测试来获得反馈，刷新就可以了。
3. 难以构建测试的环境
有时候想要写一个测试真的非常困难，试想你正在开发一个模拟小球碰撞的模块，你想写一个测试来验证碰撞后的结果符合你的预期，例如看看碰撞前后的速度变化，位置变化等等。但是这样的测试写起来非常困难：
- 两个小球的初始位置、初速度、碰撞后的速度，都要设置成非常特殊的情况才能写一个测试
- 小球碰撞这个行为虽然很简单明了，但是背后的实现却相当复杂。一开始就引入测试，会导致实现的跨度非常大，不符合TDD中增量的思想
- 即使这个测试通过了，仍然不能信任碰撞的情况。
当你发现难以构建测试环境或者无法增量开发时，你需要冷静一下，过早引入测试会让你束手束脚，并且测试会长时间处于不通过的状态。这一点都不TDD。
总结来说，一切无法快速测试的环境都不适合TDD，快速测试是TDD周期的前提。
关于TDD的研究
有关TDD的有效性和成本已经有很多研究了。下表是个总结
| 作者/年份 | 重要发现 |
|---|---|
| Siniaalto,2017 | TDD不总是能提高开发效率，特别是在对TDD不熟悉的情况下。但是TDD所生产的代码具有更高的测试覆盖率。 |
| Neil,2017 | github上使用TDD开发的Java项目非常少，将TDD开发的项目与其他项目进行对比，并没有发现TDD开发的项目有明显的优势。 |
| Wilson,2016 | TDD能够生产更好质量的代码，但是开发效率不如TLD（开发完再测试） |
| Davide,2016 | TDD声称的好处可能不是由于其独特的测试先行产生的。但类似于TDD所鼓励的细粒度稳步的增量式开发，可以改善开发质量 |
| Nagappan, 2008 | TDD消除缺陷是40% ~ 90%,其成本在开发初期多出15% ~ 35% |
| Sanchez,J.C,2007 | TDD产生的缺陷密度低于行业标准。TDD或许能减少代码复杂度随着软件年限而增长的程度 |
| Bhat,2006 | TDD的使用可以让代码质量提升，初始成本增加至少15% |
| Siniaalto,2006 | 有些情况，TDD会大幅度提升效率，大概在2/13的情况下回减低生产效率（但会提升代码质量） |
| George,2003 | TDD开发的代码质量更好（可以多通过18%或者更多的功能测试），且多用16%的开发时间。事后测试的代码测试不够充分 |
一个研究或许不具有说服力，但是大半的研究都显示了相同的结果，为以下两点提供了强有力的证据：
- TDD会开发出质量更高的代码
- TDD会增加原始开发时间
以下几点假设还没有相关研究：
- TDD可以减低长期成本
- TDD产生的测试可以减少回答关于系统行为问题的时间
TDD对我的影响
TDD是一种开发方式，或者说是一种开发习惯。有的人能够接受它，有的人觉得不合适。关键是要去试一试，只有去尝试过了，才有资格去评判它好还是不好。
对于我而言，TDD影响我最深的有两点。第一点，学习过TDD后，测试的概念已经深入我心了。以前，我对测试并没有概念，认为这是QA应该做的事情。但学习过TDD之后，我充分地了解了测试的重要性，并且知道如何编写高质量的测试。第二点，增量开发。以小步增量性地开发复杂的系统，每一步都以最简单粗暴的方法完成需求，并且通过重构来优化设计。增量性的开发思维，减少了预先设计，将所有设计都做了拆分，每次在重构的时候就是一小次设计的过程。预先设计可能会让你陷入思维旋涡，为了追求设计的完美，你可能会思考每一种可能发生的情况，并期望设计出一种可以应对所有情况的软件，但通常预先设计是过度设计，甚至是错误的设计。用增量性地开发方式替代预先设计，这是TDD与传统开发方法最大的区别。
TDD的思想还改变了我的工作模式。以我自己为例子，和大家分享我是如何在开发 Audio SDK 时使用TDD思想，并提高开发的效率。
第一点：无论如何，重构之前先写测试
我进入公司后的第一件事情，就是给我们所有音频算法写demo。当时的出发点非常简单：我想要对现在的音频算法做一些重构，例如提取公共模块，统一接口等等。既然是重构，那么我应该先写好测试，防止在重构的时候引入其他的bug。但是有个问题，就如前面提到的那样，TDD并不适合算法的开发，或者说单元测试不适合算法的验证。另外，音频算法的结果通常需要人去听才能判断是否符合预期，这种有物理边界的情况，自动化测试显得无能无力。
种种迹象表明，这类测试只能放在集成测试或者回归测试当中。因此，我们组内就建立了一个 sample-by-sample 对比机制，用来对比音频算法的结果。
这个对比系统已经运行了好几个月了，结果表明它确实是相当有用的，主要体现在这几个方面：
- 增强我们交付的信心。我们整个团队的代码更新速度是非常快的，两周一个版本，这种快速的版本更新必然会带来代码管理的巨大工作，比如各个分支的合并，解决代码冲突等等。你是否担心过不小心合错分支，或者搞错了代码冲突？大部分人可能都有过类似的顾虑。有了这套对比机制后，对于代码管理的顾虑可以减少不小。每次代码的提交都会生成对比报告，通过报告可以知道音频SDK的核心，音频算法模块，是否是正常的。如果一切都符合预期，那么当前代码就是可交付的。
- 提早暴露隐蔽的bug。通过这个对比机制，我们还抓到过几次非常微妙的算法bug。例如一些变量没有初始化，多次对比的结果出现随机化的差异。当预期不应该出现差异的修改，结果出现了差异，那么我们就应该警觉起来了，很有可能是在代码修改的过程中不小心引入了bug。
- 算法重构更加便利。算法重构提交后，CI会自动运行算法得到结果，还可以和重构前的结果做对比，非常的直观。
第二点：用单元测试来减少沟通成本
单元测试的文档性，可以减少沟通的成本。从我自身的体验来说，TDD 产生的测试确实可以减少回答关于系统行为问题的时间。
想必大家都有跨地合作开发的经历，跨地沟通成本是比较大的，而且合作写代码这件事情也比较麻烦，毕竟代码这东西很难一两句话就说得清楚。但如果我们用单元测试作为辅助手段，你就会发现沟通起来顺畅不少。比如深圳的同事说：嘿，这个模块我写好，你帮忙看看。我：好的，没问题。接着我就去看他写的单元测试。单元测试比起单纯的代码 review 有几个优势：
- 单元测试的标题描述了代码的行为。这一点让我们比较宏观的了解模块的功能和行为，避免代码 review 时陷入细节的旋涡之中。此外，你也可以根据单元测试来估计模块的完成度是多少，是否有某些行为没有被测试。
- 单元测试是独立可运行的最小单元。可运行这一特点比起单纯代码 review 就进步太多了。通过单元测试的组织结构（3A/Given-When-Then）可以了解代码是如何交互的，它们产生的结果是什么。这样的单元测试就是一小个一小个 demo，让你逐步了解如何使用这些代码。因此，你完全可以按照自己的理解对一些变量进行修改，然后给出预期的断言。如果断言都通过了，说明你理解了这部分的代码，就不用揪着同事问为什么这里是这样的呀？这一点还可以帮助你快速的上手开源代码。如果一个开源的代码提供了完备的单元测试，我们就可以通过单元测试知道代码的行为和交互，再配合阅读官方的文档，能够起到事半功倍的效果。
当我们习惯将单元测试作为沟通的辅助手段后，沟通起来就会变得相当有趣，比如
A: 嘿，这种情况你要考虑过吗？
B: 有的，在xxx单元测试里
或者
A: 我期望的代码行为应该是这样的，我把它写到xxx这个测试里
B: 好的，看完那个测试我明白你的意思了，你是想…
再或者
A: 在这种情况下，代码有个bug
B: 好的，我先用单元测试复现这个bug，然后再解决它
没有什么是一个单元测试解决不了的，如果有，那就两个。