51Testing软件测试网 m f@4? |
W0P 引子
D%b/TYW03ZI9Z9x)oD
n0 单元测试在开发人员中的普及,障碍很多。单测技术除外,单测意识问题、对单测收益的疑惑、做起来以后怎么持续等等,打击着开发人员开始单元测试的决心。写这篇文章,也真是为了消除大家对单测的疑惑,提高对单测的认识。认识的飞跃让你轻松面对单测,不把单元测试当负担,提升代码质量的同时,提升自己的设计能力,甚至尝试开发模式的变革,爱上单元测试并爱上开发。
??8V5\#B$?aU
N%O+_07KKQ&S^l NO0 一些记忆犹新的回忆
#H5d6~5tK
Rv ejb051Testing软件测试网xw%E-|Q1N3S1N/Q
十多年前,作为开发人员进入了某大公司,有幸还是不幸进入了CMM2到CMM4的试点项目组。“V”模型,coding完后UT。清晰记得胖胖的女
QA,要求100%的行覆盖率,85%以上的C/D覆盖率。加班到11点,因覆盖率而失眠,是否发现很多bug,已经不记得。回头想想,当时的目标是明确
的,各种覆盖率,完美的单元测试报告,可以顺利的进入集成测试阶段。
o0B;RT5K,l!i(|0dO0_-Q/e)D$C3]F0 后来转战了一些公司,开发人员做单元测试依然是不成文的规矩,没有那么严格,有测试报告就好。终于有一天,我成为了“擎天柱”。51Testing软件测试网:`Q%D
E^^:Q'G
51Testing软件测试网n,x/RW:Hk,t
开发关联引擎,自鸣得意于架构、各种设计模式。很多关联关系没有考虑清楚,没有做全面的单元测试,悲剧了!同样悲剧的王五,做的是客户端。接下来的日子
就是加班改bug,为了没有考虑到的关联关系增加特殊处理代码。“精美”的设计不再存在,糟糕的代码质量是第一映像。痛苦的经历,人也正是经历了痛苦才长
大。
?qB/l4a%v])A0Ky$S?6{7d;w:\#zK0 工作多年开发了很多C/S架构的系统,系统测试阶
段问题定位最为痛苦。Client端的开发人员先排除问题,而后再转到Server端的开发人员排除。如果前后两端都有问题,也许要改多次才能通过。项目
结束后的bug分析总结,50%以上都写着bug产生原因:单元测试不充分。问题定位成本的1:10:100,说明了问题,系统测试阶段的问题定位成本是
最高的。
\s ~WT1x$Bf7CN051Testing软件测试网M4D.?K h7p ……
9z3QE,K'k8I
c.Z051Testing软件测试网:O2Sj nWb 故事还有很多,记住了这些,对单元测试的意识还只是初级阶段。意识到了:51Testing软件测试网? xn;S7Nyovg-fA
51Testing软件测试网8}+m`'J/N3a]MX ● 单测能降低bug发现成本;51Testing软件测试网Mtf$~2IVU
51Testing软件测试网;s\L7anS,u ● 单测能提高提测质量;
bwX4}i.f&rn051Testing软件测试网Y?'l8p3B
H ● 单测粒度可以用各种覆盖率来衡量;51Testing软件测试网"u1QhZ,`*q;b'?K4f4c
l8y*\q N@
icV.C0 没有技术含量的配置管理
?)PX"J jx6hw051Testing软件测试网r5t&a.y!I8f
m
年轻难免心高气傲,进入知名企业,都期待的干有挑战性,前沿的技术活。你在最求卓越、最求新技术的时候,是否忽略了一些不起眼的小事呢?你的开发机上是
否还有别人不知道的自测脚本?你是否每日提交自己都不确认正确的代码?你是否先开始写代码再边写边想目录结构?如果你的回答都是“是”,恭喜你,你还是不
成熟的小码工。
.uV-z"E-p$|051Testing软件测试网J)h"U)L0UXT1G@ 大家很幸运,没有经历过产品代码只有在某几个人电脑中有情况。来到百度就
知道SCM,就知道SVN,但是对配置管理还是认识不够。边写代码边考虑目录结构,就意味着会忽略测试脚本的存放目录;测试机和本地还有别人不知道的自测
脚本,意味着没有做到测试case与代码同源,没有真正意识上的自动化。想起以前开发团队中的两个同学,提测质量都很高,都做单元测试。不同的是,A同学
使用xUnit写测试case并提交配置管理,B同学是用main函数来做单元测试且不提交配置管理。B同学平时测试时重新main,或到本地找测试
case的成本自己是可以忍受的,终于有一天,系统崩溃了,所有的测试case都没了。
;s6B
p$X6u9_r8a051Testing软件测试网7Z/{*j7NF _ 开始单元测试前,花时间了解一下“没有技术含量”的配置管理,能让你的单测case发挥更大的作用。
1Cp4kWBj4H0Y,^%vJ4N'?Q6]_0 开始了单测,但依然是被动接受
kqo'y+SnmEe051Testing软件测试网0CH-j[5}h 也许骨子里就是将开发和测试严格分离,很长时间都是先写完代码才考虑测试。其实很多开发人员都有我同样的习惯,成千上万代码完成后,再来补单测
的心情可想而知了。是不是的会冒出这样的想法:写类似接口测试的单测尽快达到覆盖率吧;就测试几个重要函数算了;单测做得太完美了,QA做什么?这些想法
说明了做单测时的被动,单测的效果无疑会大打折扣。在这种想法的驱动下,“大单测”的概念也会产生,接口测试和单元测试的差异也被模糊,自然不会理解没什
么还需要QA?为什么要用stub或mock?
.cTGWN-F9OsJ051Testing软件测试网"?h#k/iQ|S;zxD 单测能帮助你尽快验证提交的代码。每日为自己生产的代码增加单测case,使用stub或mock技术隔离依赖,代码提交前在本地执行单测
case(local build),这些好的习惯无疑能消除你补测试case的苦闷,主动的单测。每日的一小步,让你代码质量更高,睡得安稳。
@ cXi3|:[8v0_k:m3VU9C2~0 代码需要呵护,持续重构
C$f.EoX\:^)a051Testing软件测试网\w%\Z$P
j0MXe-k 单测的意识在不断的提高,然而新的苦闷又来了。成长的代价,让我留下了太多没有单测的代码,它们依然在使用、在升级,下定决心来补充单测吧。
“这代码怎么写得这么烂?”“这个函数我没法写出单测case了”,自己给自己挖了很多坑。这时,是放弃单测还是重构后继续单测?从短期成本来看,应当放
弃;但长期来看,必须重构。每一个开发人员都希望大家认可自己的代码,希望有写代码的成就感:功能好用、性能优良、代码很美。不可测的方法、代码中的坏味
道需要找时间将它们消除掉,唯有持续重构:在修改bug时顺便重构;在增加新功能时重构;利用CR的机会重构。为了那一份荣耀:读你的代码如欣赏优美的艺
术品,这些工作都值。51Testing软件测试网6up|#Qzgx9p
`5Ln;g nQ"j0 到处,我已经不再仅仅考虑软件的外部质量,而会同时关注内部质量,可测性、洁净代码原则和方法,我都会考虑,开发活动因此而更加丰满。
`0Y0^ lU1R/J0f6y-R5L(p_)O;HC0 不再只是小码工,也是架构师51Testing软件测试网7P h7ZpdC
51Testing软件测试网|*nWyiV 经历了将模块全面推翻重构的苦痛(严格说是重写了),我们会开始思考,为什么不能将思考提前,为什么不能未雨绸缪呢?现在我们还是完整的详细设
计,开发,再测试,不过我们每天都为提交的代码写测试case,及时的发现代码可测性问题。测试和开发依然界线分明,为了实现设计而编码,为了验证编码而
测试。能不能将测试case提前?能不能让测试来指导设计?TDD终于出现了。我是08年接触到TDD,不过现在它依然很“新”,没有被广泛的实践,它将
带来开发模式的变革。
"~'O8R,Y3KE051Testing软件测试网0u:`zt/v:~+\w 用一句话描述TDD:写代码是为了修复失败的测试。它是一种分析技术、设计技术。
WU~\5N/s!\051Testing软件测试网!^c/n#qc5P 测试先行,开始编码前你已经想到了怎么去测试、准备好了测试case,代码可测性问题提前考虑,依赖倒置原则(DIP)、开闭原则(OCP)、
单一职责原则(SRP)都会用来指导你的设计,这样的代码写起来感觉很好。你又向前迈进了一步,不再只是小码工,也是架构师了。
7vB8^.MRG"J0!p5rwq&R2a2_`4r/G0 测试让我更爱开发
TE8jj9oV%qo:FH04{ P
zB3W/H'K4r0 一路走来,我的单测意识在升华,经历单测之惑、单测之需、单测之痒、单测之法、单测之美,消除了开发中的许多烦恼,有了一套可预测的开发方法,
知道什么时候可以完工,不再担心长期被bug困恼;能不断的重新认识代码,重构它让架构更合理。测试让我享受着设计和开发,让我更爱开发。
rHU'S3FcA-]S^#T0