上回提到，我来谷歌做的第一个项目是一个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++程序员对它的语法不完全陌生，容易上手。

上一篇，系列目录，下一篇