在研究敏捷开发中的TDD过程中, 接触到了UT(UnitTest)框架的概念.The Lego Batman Movie (2017)
在我的印象中, 自动化测试只需要每一个C模块中写一个对应的测试代码文件, 然后在Makefile稍加修改即可完成, 类似下面这样:
//module_a.h
int module_a_dosomething();
//module_a_test.c
int main()
{
module_a_dosomething();
}
//Makefile
....
test:module_a_test
./module_a_test
module_a_test:module_a_test.c module_a.c module_a.h
gcc -o $@ $^
只要略做扩展不难实现所有模块的自动化测试, 实在想不到UT框架有什么用.
本着存在就是有道理的原则, 研究了一下gtest. 发现我之前的理解并没有什么原则上的错误, 只不过UT框架提供了一些很方便的接口.
在上述不使用UT框架的方案中, 所有的代码测试打印均需要自己处理, 每一个模块的测试代码可能都含有相同的测试逻辑, 造成代码冗余.
将这些相同的测试逻辑抽出来进行整理, 一套UT的框架就可以产生了.
以google开源的UT框架gtest为例.
gtest中的ASSERT_*, EXPECT_*, TEST_F…等宏可以用来格式化输出test case的执行情况， 使得测试过程中结果更为清晰， 在编写test case时可以专心编写测试逻辑而几乎不需要关注测试打印的问题.
gtest将一些大部分test case代码中都会用到的测试逻辑提练出如事件、参数化、死亡测试, 运行参数等机制, 并导出接口供test case代码使用. 使得test case代码大大缩短, 测试逻辑可以更简单明了.
因此UT框架几乎是自动化测试的发展的必然产物, 当然到底是封装成Framework还是library, 这就要看作者的心意了.