单元测试实践
· 如何编写有效的单元测试用例
单元测试的组成部分
一般单元测试由以下几部分组成：
1. 测试数据：尽可能稳定，减少对不确定性因素的依赖。
2. 逻辑执行体：要明确当前测试用例测试的是哪个函数、哪个分支逻辑，不要一次性覆盖大多。
3. 结果校验：尽可能完整，不要只校验函数返回值。
单元测试的原则
单元测试必须遵循的原则：
1. 独立性：单元测试是独立的，可以单独运行，并且不依赖于任何外部因素，如文件系统或数据库。
2. 幂等性：每次运行单元测试应与其结果一致，测试中不要依赖如时间、日期等不确定因素。
3. 快速：不要依赖网络请求等耗时操作。
经验小结
编写单元测试时建议从以下角度思考：
1. 实现什么功能，处理哪些数据，最终输出什么？
2. 异常和边界在哪里？
3. 函数的关键结果是否都验证到？包含返回值和中间值。
4. 函数的风险在哪里，哪部分逻辑不太自信，最容易出错。
5. 并不是所有函数都需要单测，如get/set等逻辑比较简单的的，不一定需要写 。
· 提高代码的可测试性
C++是一门多范式的语言，而且由于C+语言本身的一些特性（RAII，模板等），网上很多基于Java等语言总结出来的提高可测试性的方法对C++来说可能过于麻烦，如依赖注入等，不一定特别适用。
下面整理了一些简单常用能提高可测试性的方式。
·影响可测试性的常见因素
· 外部依赖过多，需要mock
· 数据依赖链过长，导致构造测试数据麻烦
· 分支逻辑过于复杂
· 全局变量/静态变量
· 内部lambda表达式过多
· 依赖的类对象不可构造/难以构造
· 函数功能过多
· 减少全局变量/静态变量的使用
如果你的对象依赖了一些全局变量/静态变量，而且这些全局变量会在多个测试case使用，这种情况是比较难测试的，你不得不在每个测试用例结束之后手动重置全局变量。这样不符合单测测试的独立性原则，所以应该尽量避免使用全局变量。
class MyTest {
public:
int GetIndex() {
return index++;
}
static int index; //静态变量
};
int MyTest::index = 0;
TEST(test, demo) {
ASSERT_EQ(0, MyTest().GetIndex());
}
TEST(test, demo2) {
ASSERT_EQ(0, MyTest().GetIndex()); //Error
}
TEST(test, demo) {
MyTest::index = 0;
ASSERT_EQ(0, MyTest().GetIndex());
}
TEST(test, demo2) {
MyTest::index = 0;
ASSERT_EQ(0, MyTest().GetIndex());
}
迪米特法则
如果你代码中引入一些复杂的外部依赖，可以考虑将依赖转移给调用方法。如：
class MyClass {
public:
void doSomething() {
if(getUserManager().getUser(123).getProfile().isAdmin()) { //bad 复杂的依赖链
//xxxx
} else {
}
}
};
class MyClass {
public:
void doSomething(bool isAdmin) { //简单的参数依赖
if(isAdmin) {
//xxxx
} else {
}
}
};
直接依赖需要的参数，避免依赖类似于Context大而全的参数。（可能非常难以构造）
如：
class MyClass {
public:
void processOrderBefore(const UserContext & userContext) { //修改之前
const User & user = userContext.getUser();
const PlanLevel & level = userContext.getLevel();
const Order & order = userContext.getOrder();
// ... process
}
void processOrderAfter(const UserContext & userContext) { //修改后
const User & user = userContext.getUser();
const PlanLevel & level = userContext.getLevel();
const Order & order = userContext.getOrder();
processOrderAfter(user, level, order); //核心逻辑抽成新的函数
}
void processOrderAfter(const User & user, const PlanLevel & level,const Order & order) {
//只需要对新封装函数进行单元测试即可
// ... process
}
};
封装分支逻辑
如果一个函数中分支太多，可以考虑将不同分支封装成不同的函数处理，然后对封装的函数分别编写单元测试用例。
合理使用MOCK工具
考虑在以下场景使用mock工具，可以减少你的单元测试成本：
1. 代码中依赖的某个功能在你本次测试并不关心，如：db数据读取，发请求。
2. 测试用例依赖一些复杂的数据源，如：db数据读取，流水线上游数据，网络请求。
3. 一些非幂等性的函数调用或者结果返回不稳定的函数调用，如：随机数获取，时间获取，db写入。
4. 对象的某些状态难以创建或者重现，如：网络错误或者文件读写错误。
5. 验证一些中间过程值，如：你的函数没有返回值，或者中间过程值不方便验证，可以mock中间某个函数调用来验证中间过程结果是否正确。
尝试测试驱动开发（TDD）
如果你的需求所要实现的功能相对明确，那么可以先把接口定义出来，写一个最简单的实现运行起来，为其补充单元测试用例，然后再一步步完善具体实现细节。
如果不能先写测试用例也没关系，重要的是在开发中尽早编写测试测试，不要将它们延迟到最后，这样可以及时重构你的代码。
· 常见误区
只测试正常数据
应当尽量补充一些特殊值（如空值、边界值）或异常数据，以校验目标函数在不同的输入是否符合预期，尽量覆盖多的代码分支逻辑。
结果校验不完整
如果你的目标测试函数中对属性进行了修改，那么应该尽可能校验这些修改是否符合预期，而不是单单只校验函数返回值。
输入数据过于复杂
1. 生成测试输入数据的代码应当避免与实际工程代码耦合，如：读取db或从流水线上游产生等。
2. 使用最小数据依赖的原则，只输入对当前测试用例会产生影响的数据即可。
3. 如果数据源构造过于复杂，可以将一个大的测试用例拆分成多个小的测试用例。
测试代码存在分支条件
避免测试用例代码中使用if、switch等分支逻辑，保持用例尽量简单，如果需要测试不同分支的代码逻辑，应该拆分成多个测试用例。
· 维护测试用例
1. 重构代码时，应该同步修改测试用例。
2. 发现新增Bug时，应当将能验证此Bug被修复的测试用例的补充到单元测试工程中。
· 测试用例命名规则参考
TEST_F(TestUCPPipelineCenter, checkTaskInProcess_重复触发_true);
测试宏 被测试类名， 被测试函数名_简单描述核心测试逻辑_要校验的结果值
小结
我们小组的单元测试工程已经稳定运行了一段时间，代码提交流程也逐步固化下来了，如下图所示。后续我们会寻找一些指标去量化衡量单元测试所带来的收益。希望本文能帮助大家更加快捷地搭建C++单元测试环境，限于本人水平，如有不足或错误之处欢迎批评指正。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
