引子

　　单元测试在开发人员中的普及，障碍很多。单测技术除外，单测意识问题、对单测收益的疑惑、做起来以后怎么持续等等，打击着开发人员开始单元测试的决心。写这篇文章，也真是为了消除大家对单测的疑惑，提高对单测的认识。认识的飞跃让你轻松面对单测，不把单元测试当负担，提升代码质量的同时，提升自己的设计能力，甚至尝试开发模式的变革，爱上单元测试并爱上开发。

　　一些记忆犹新的回忆

　　十多年前，作为开发人员进入了某大公司，有幸还是不幸进入了CMM2到CMM4的试点项目组。“V”模型，coding完后UT。清晰记得胖胖的女QA，要求的行覆盖率，85%以上的C/D覆盖率。加班到11点，因覆盖率而失眠，是否发现很多bug，已经不记得。回头想想，当时的目标是明确的，各种覆盖率，完美的单元测试报告，可以顺利的进入集成测试阶段。

　　后来转战了一些公司，开发人员做单元测试依然是不成文的规矩，没有那么严格，有测试报告好。终于有，我成为了“擎天柱”。

　　开发关联引擎，自鸣得意于架构、各种设计模式。很多关联关系没有考虑清楚，没有做全面的单元测试，悲剧了！同样悲剧的王五，做的是客户端。接下来的日子是加班改bug，为了没有考虑到的关联关系增加特殊处理代码。“精美”的设计不再存在，糟糕的代码质量是第一映像。痛苦的经历，人也正是经历了痛苦才长大。

　　工作多年开发了很多C/S架构的系统，系统测试阶段问题定位为痛苦。Client端的开发人员先排除问题，而后再转到Server端的开发人员排除。如果前后两端都有问题，也许要改多次才能通过。项目结束后的bug分析总结，50%以上都写着bug产生原因：单元测试不充分。问题定位成本的1：10：100，说明了问题，系统测试阶段的问题定位成本是高的。

　　……

　　故事还有很多，记住了这些，对单元测试的意识还只是初级阶段。意识到了：

　　● 单测能降低bug发现成本；

　　● 单测能提高提测质量；

　　● 单测粒度可以用各种覆盖率来衡量；

　　没有技术含量的配置管理

　　年轻难免心高气傲，进入知名企业，都期待的干有挑战性，前沿的技术活。你在求卓越、求新技术的时候，是否忽略了一些不起眼的小事呢？你的开发机上是否还有别人不知道的自测脚本？你是否每日提交自己都不确认正确的代码？你是否先开始写代码再边写边想目录结构？如果你的回答都是“是”，恭喜你，你还是不成熟的小码工。