财新传媒
位置:博客 > 万战勇 > 我在谷歌弄啥咧之三:上马gtest

我在谷歌弄啥咧之三:上马gtest

上回提到,我来谷歌做的第一个项目是一个C++测试框架,叫gTest。考虑到有的朋友不是程序员,我来解释下这到底是个什么东西:软件工人不好当,常挨bug放冷枪。无时不刻谨提防,如何自卫费思量:与其被动很受伤,不如把它都杀光。奈何bug多且强,不肯老实见阎王。你要杀它它更忙,死而复生亦寻常。要想不为它抓狂,自强不息勤修养:大干快上太莽撞,多写测试才健康!
 
所谓测试,就是一段程序,它的目的就是自动检验另一段程序做的事是不是正确。写测试的目的,是为了保护你的代码不被bug侵蚀,一旦有bug来挑衅,可以在第一时间发出警报。测试框架,就是一个让测试更好写、更规范的工具,可以把你编写和维护测试的痛苦降到最低。我们的口号是:一切没有测试的编程,都是耍流氓。
 
既然测试这么要紧,那肯定各种测试工具都被人做得尽善尽美了?我当年也是这么想的,结果侦查的结果让老夫一口枸杞喷在24寸的液晶显示器上:给C++语言(谷歌使用最多的编程语言)开发的测试框架倒是很多,好用而又能满足我歌需求的还真是找不出来。几年后,我写了一篇英文的 《C++的测试框架啊,咋就这么多捏?》,说的就是这事。据我说,造成这种局面的主要原因在于:
 
- C++用得太广泛了,各种硬件,各种操作系统,各种牌子和版本的编译器,都在跑C++,但是又各有差异。甚至编译时不同的命令行参数都会影响到哪些功能可以用。虽然它们都叫C++,其实各有各的小九九。就好像咱中国地大人多,虽然都用中文,你让上海宁港广东瓦也是强人所难。所以,很难写一个在各种环境下都能工作的C++测试框架。
 
- C++自身的一些缺陷,比如缺乏“反省”(reflection),造成一些重要功能(比如测试案例的自动注册)比较难实现。
 
- 很多框架的作者满足于解决自己小环境的问题,没有花更多的力气考虑系统的可扩展性。结果是如果你的需求正好是它的子集就好办,如果不幸超过了系统的设计预期就悲剧了。这样,谁的框架都不能一统江湖。
 
因为谷歌要在各种环境下用C++,我们需要一个适应性强,可以让用户轻松扩展的测试框架。另外,很多同学对写测试其实是抗拒的,认为没有写功能爽快有成就感。尤其是在很多其他公司开发和测试是完全分开的岗位,开发员只管写功能和杀bug,测试员只管写测试和挑刺。从这些公司来的同学,有一个适应我歌开发测试一体化文化的过程。这种情况下,如果测试工具很难搞,岂不是自寻绝路。所以,为了降低大家对写测试的敌意,提升大家写测试的喜感和效率,甚至写测试成瘾,这个框架一定要贴心好用让人欲罢不能。这一点我觉得现成的框架不是很令人满意。
 
著名推理家福尔摩斯基在他的自传中说过,如果一件事有N种可能,但是其中N-1种可能都被证明其实不可能,那么剩下的一种可能,不管多不可能,都是唯一的可能。所以,我别无他法,咬牙决定自己开发gTest解决上面说的这些问题。
 
我读博的方向是面向特定领域的编程语言(DSL,即Domain-Specific Language,),其主要思想是:通用的编程语言就像万精油,头疼脑热都可以上,但具体到某个特定的领域不一定是最佳选择;如果针对一个领域的特点来定制一个语言,用户可以得心应手,如鱼得水。当然,开发一个全新的语言有很大的代价,不光是技术上的困难,让用户高高兴兴地学习一门新语言通常也是不现实的。所以,我们采用的策略是做嵌入式DSL,就是在一个通用语言的基础上,加入一些新的宏定义和词汇做一个库,用起来感觉就像一门不太一样的语言。打个比方,我们知道有一种语言叫“网络语言”,虽然它还是属于汉语,但是用在《人民日报》显然是不可能的,这是因为它有特定的受众和适用环境。我想把gTest按DSL来搞,既针对测试的需求深度定制,又让C++程序员对它的语法不完全陌生,容易上手。

上一篇系列目录下一篇



推荐 14