软件测试工作让我更爱开发

　　引子

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

　　一些记忆犹新的回忆

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

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

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

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

　　……

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

　　单测能降低bug发现成本;

　　单测能提高提测质量;

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

　　没有技术含量的配置管理

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

　　大家很幸运，没有经历过产品代码只有在某几个人电脑中有情况。来到百度就知道SCM，就知道SVN，但是对配置管理还是认识不够。边写代码边考虑目录结构，就意味着会忽略测试脚本的存放目录;测试机和本地还有别人不知道的自测脚本，意味着没有做到测试case与代码同源，没有真正意识上的自动化。想起以前开发团队中的两个同学，提测质量都很高，都做单元测试。不同的是，A同学使用xUnit写测试case并提交配置管理，B同学是用main函数来做单元测试且不提交配置管理。B同学平时测试时重新main，或到本地找测试case的成本自己是可以忍受的，终于有一天，系统崩溃了，所有的测试case 都没了。

　　开始单元测试前，花时间了解一下“没有技术含量”的配置管理，能让你的单测case发挥更大的作用。

　　开始了单测，但依然是被动接受

　　也许骨子里就是将开发和测试严格分离，很长时间都是先写完代码才考虑测试。其实很多开发人员都有我同样的习惯，成千上万代码完成后，再来补单测的心情可想而知了。是不是的会冒出这样的想法：写类似接口测试的单测尽快达到覆盖率吧;就测试几个重要函数算了;单测做得太完美了，QA做什么?这些想法说明了做单测时的被动，单测的效果无疑会大打折扣。在这种想法的驱动下，“大单测”的概念也会产生，接口测试和单元测试的差异也被模糊，自然不会理解没什么还需要QA?为什么要用stub或mock?

　　单测能帮助你尽快验证提交的代码。每日为自己生产的代码增加单测case，使用stub或mock技术隔离依赖，代码提交前在本地执行单测 case(local build)，这些好的习惯无疑能消除你补测试case的苦闷，主动的单测。每日的一小步，让你代码质量更高，睡得安稳。

　　代码需要呵护，持续重构

　　单测的意识在不断的提高，然而新的苦闷又来了。成长的代价，让我留下了太多没有单测的代码，它们依然在使用、在升级，下定决心来补充单测吧。“这代码怎么写得这么烂?”“这个函数我没法写出单测case了”，自己给自己挖了很多坑。这时，是放弃单测还是重构后继续单测?从短期成本来看，应当放弃;但长期来看，必须重构。每一个开发人员都希望大家认可自己的代码，希望有写代码的成就感：功能好用、性能优良、代码很美。不可测的方法、代码中的坏味道需要找时间将它们消除掉，唯有持续重构：在修改bug时顺便重构;在增加新功能时重构;利用CR的机会重构。为了那一份荣耀：读你的代码如欣赏优美的艺术品，这些工作都值。

　　到处，我已经不再仅仅考虑软件的外部质量，而会同时关注内部质量，可测性、洁净代码原则和方法，我都会考虑，开发活动因此而更加丰满。

　　不再只是小码工，也是架构师

　　经历了将模块全面推翻重构的苦痛(严格说是重写了)，我们会开始思考，为什么不能将思考提前，为什么不能未雨绸缪呢?现在我们还是完整的详细设计，开发，再测试，不过我们每天都为提交的代码写测试case，及时的发现代码可测性问题。测试和开发依然界线分明，为了实现设计而编码，为了验证编码而测试。能不能将测试case提前?能不能让测试来指导设计?TDD终于出现了。我是08年接触到TDD，不过现在它依然很“新”，没有被广泛的实践，它将带来开发模式的变革。

　　用一句话描述TDD：写代码是为了修复失败的测试。它是一种分析技术、设计技术。

　　测试先行，开始编码前你已经想到了怎么去测试、准备好了测试case，代码可测性问题提前考虑，依赖倒置原则(DIP)、开闭原则(OCP)、单一职责原则(SRP)都会用来指导你的设计，这样的代码写起来感觉很好。你又向前迈进了一步，不再只是小码工，也是架构师了。

原文转自：http://www.ltesting.net