单元测试实施解惑(一)
上一篇 / 下一篇 2012-09-11 13:42:25 / 个人分类:单元测试
:F!k+~|TX)}7yz0 在刚过去的一个月中,我完成了一个小软件框架的设计与实现。期间由于并行开发的需要,在没有对代码完成单元测试的情形下我将之check in到了SVN的主干上,随后的心情很是忐忑。因为我知道我一定会犯错(事实也证明在单元测试完成之前就发现了两个缺陷),害怕给他人带来麻烦并影响自己的形象。51Testing软件测试网(yF0a7|8yN
51Testing软件测试网5pzW4w:n^(C#Hs另外,由于对刚加入项目的单元测试环境完全不了解,所以在该框架的前期开发工作中 我并没有运用单元测试渐进地保证软件质量。其结果可想而知,我花了不少时间去修复编码过程中遗留下来的低级错误。需要指出的是,所在项目是一个大型嵌入式 系统,项目编译一次就得20分钟左右,调试效率可以想象。与之不同的是,单元测试可以在Linux/Cygwin这样的环境中完成,加上可以使用gdb进 行调试,开发效率提高一个数量级应不是问题。
`+q@+C)J0,Z)_6\*Qfy5B)Z%P c0 由于我深刻地体会到了单元测试对工作与生活质量的重要性,所以持“真正高质高效的软件开发工程师,一定是那些深刻理解并切实实施单元测试的人”这一观点。然而,就我过去几年的工作见闻来看,发现身边绝大多数的工程师并没有真正用心去拥抱单元测试。出现这样的状况,我认为存在一定的原由,因此想借本文谈谈一些认识。
QB)@,v9s I}W0z051Testing软件测试网x][L ^7i ZoaN有相当一部分工程师是因为并不了解什么是单元测试而没能尝到单元测试的好处。一部分人认为,平时开发工作中的调试其实就是单元测试(参见《明析单元测试》),有的则因为没有花时间学习单元测试而对之不了解。对于这些新手,我并不打算在本文对之“扫盲”,请下载ClearRTOS源码(点击下载)和本文的附件自行学习。 ClearRTOS 是我为《专业嵌入式软件开发》一书所设计的、可在Cygwin和Linux环境中运行的“实时”操作系统,其中涵盖有单元测试方面的内容,更具体的信息见文后。51Testing软件测试网I%P!kw~(y[b
51Testing软件测试网D@ [,|qV另外的一部分人尽管实施过单元测试,但却没能从中受益,甚至得出“单元测试无用”的结论。这部分人的困惑是我最想在这里加以指出的。归结起来,我认为实施过程中的“缝太大”是其中一大主因。
Ka{"E]}NaX*RB0Sv E;LoP3B(b0 不少团队将项目的产品代码与单元测试代码加以区别对待,这是产生“缝”的第一大根源。表现之一是,编译产品代码与编译单元测试代码采用完全不同的编译环 境,程序员在日常工作中需要不停地在两个编译环境中进行切换。这种方式很容易让工程师感到麻烦,甚至因此遭到抵制或弃用。好的方式是,将单元测试代码的编 译环境与产品代码进行无缝整合。比如,在嵌入式系统项目中做到运行“make release”或“make debug”实现产品代码编译,运行“make unitest”完成单元测试代码编译(ClearRTOS项目就是这么做的)。做到编译环境的无缝整合需要团队中存在精通编译环境构建语言(比如 Makefile)的专家。很不幸的是,这方面的专家少得可怜,团队对这方面知识的精进也因为没有意识到其重要性而缺乏动力。
^vMfI_9z'h0