记一次单元测试奇怪问题

前言

本人就职一家头部金融周边公司，熟悉本行业的人应该知道该行当的项目代码有几个特点。

难度不高、技术老旧、超多文档、环境依赖复杂、测试困难。难度不高、技术老旧，本萌新初入公司，也曾不知天高地厚试图升级迭代本屌管理的模块，初始成功将本模块从vc6.0升级到vs2010，幸而本屌学识不深，但微软对于以稳定闻名的win7sdk为基础的vs2010也颇为值得信赖，让我小鸟我经过不长的项目周期就的以升级成功。就是这一次升级也让本鸟初识本行当的精髓”牵一发而动全身”。鉴于本鸟动了项目的基石，依赖的sdk从vc6.0升级到vs2010拉，编译器也随之升级，而且我们又是很敏感的项目周边，客户是真正在上面交易的，出了问题可就不是本鸟能承担的了。所以老成的测试慌得不行，又因工作地点不同，鞭长莫及，无奈给本鸟做了个全面测试。这一测试，可真真是好家伙，我严重怀疑测试自己预留了一项遗留bug手册，全是前任开发们推诿认为不影响使用，没有修改的bug全部丢过来了，大大小小几十个吧，本鸟虽然知道与我无关，但奈何终究还是年少轻狂，不懂其中奥妙，一股脑加班加点从头撸下来了。索性项目难度着实不高，还能hold住。经此一役，测试对于本鸟大为改观，本鸟也短时间自信心爆棚，开始了接下来让我后悔莫及的重构大业。

重构篇

因此役干的不错，leader也颇为赏识，于是给我发下来新的任务，把现有的几个分支版本归一，总的说来需求不算难，关键在于架构和兼容。本鸟刷刷一顿整，很快就把架构弄好了，奈何本鸟老毛病又犯了，看到现在乱成一团的代码史山实在是百爪挠心，难以下咽，于是就动起了重构的念头。本鸟心想这归一也需要全面测试的，何不趁此机会一起撸了呢。最终这一决策面临紧张的项目时间、复杂的测试环境终究还是折戟沉沙。索性leader为人颇好，知道此为历史遗留问题，前人也一直想弄都没有完成，没有追究本鸟的责任。本鸟因前面的原因，有新的oem需求，所以就拿着自己写的半成品框架（只重构了关键的买卖模块），就去开发扔给测试了。索性客户需求的功能较为简单，但测试也是状况百出。因为本鸟虽然对代码架构掌握的不错，但对于发布所需求的很多东西不甚清楚，导致状况百出，测试也颇有微词。腰杆不硬，对于测试拒绝合一版本的测试也无能反驳，终究导致leader心心念念的版本合一，以及自己的重构大计落空。对此自己也是幡然悔悟，总结有二，其一，工作并非学习，学习要求多元化，一系列的知识脉络最终构建为自己掌握的知识体系，工作则不尽然，工作要求短、平、快，项目周期尽量短，如果过长就拆解树立短期目标，处理期间不要擅自额外增加东西，因为你手头上做的东西指不定就出现什么状况需要你额外花时间处理、风险尽量可控，风险不可避免，但是要能区分什么是风险点，不要将多个风险点放在一个项目周期去完成，这样最简单的是控制变量法将无所依，大概率伦于扯皮拉钩，项目流产。其二，开发自己应当有自己的单元测试意识，如果自己对自己的代码都不够自信，又如何去信赖测试基于实际应用场景的白盒测试呢？问题依然在哪里，只是没测试到罢了。

单元测试篇

vs2010下开发的mfc项目，选用大名鼎鼎的GTest框架，因为眼馋GMock嘛。待测试的是个dll，依照教程，依赖DEBUG新建GTEST_DEBUG,生成文件改为应用程序，编译，链接，输出.exe，简单easy，结果好家伙，exe无法在本系统运行，您是虾米玩意？首先怀疑项目配置问题，项目太大不好排查，手建一个demo，毕竟也没干过此类事情，理论是链接不一样就行了，结果证明demo是可行的。检查下demo与本项目的链接命令不一样，本项目多了个/DLL,这一看就有问题了，我输出的exe咋链接命令里面有/DLL了，对比demo和本项目的链接配置，没有发现目标。折腾良久，文本编辑器看下project文件把，好家伙，一下就看出问题了，我新建的GTEST_DEBUG下的LinkDLL还是true，我明明把输出改为应用程序了，这里没有变过来，demo就自己变为false了。只能归咎于vs2010的bug了，项目太大，ide也会处理出错，手动改下false，嘿输出一个windows能识别的exe了。

总结

vs的ide很强大，能够很直观的为我们做很多事情，但是作为开发，要尽量当一个知其然，更知其所以然的深究者。而不是表面会操作ide，生成修改代码就行了，而要深层次的理解编译使用的什么，链接使用的什么，其编译链接的配置是什么，ide修改的对应是什么。否则哪位倒霉的仁兄碰到我这问题大概率就中道崩殂咯。怀念linux多一秒。