单元测试进行曲 单元测试
又是老生常谈-'单元测试'，说实话自己在单元测试上是'语言上的巨人，行动上的矮子'，属于那种说的比做的多的人^_^。不过也不能说什么也没做。记得去年年末的时候自己还设计并实现过一个简单的'C语言单元测试包'呢^_^，至今这个包仍然还在使用呢。不过大多数的单元测试都不像想象中那样简单，我们在介绍单元测试的时候，大多拿Add、Sub等作例子，这样当然有好处，简单易懂。其实学习单元测试初期关键是学习单元测试的思想，所以这些Add、Sub也能满足需求。不过在真正的项目中，单元测试大多做起来较为困难，我是在Unix上做C开发的，Java的咱暂先不提，也没什么资格提，虽然曾经花过一段时间专心研究过，还写过些Java学习心得，但是毕竟没做过实际的项目，说起来心里也发虚。
曾经很长一段时间，自己在编码阶段基本上都是缺少单元测试的，一是项目中Legacy代码较多，耦合太紧，想把那部分代码拿出来比'登天还难'(有点夸张)，反正基本上是'一扯一大帮'，俗称'一个都不能少';而是部门在这方面积淀较少，在计划的时候对这方面考虑不够，时间上也不充裕，经常是在集成测试或者系统测试的时候顺便带上单元测试了，这样的后果就是'浪费'。本来在单元测试阶段发现一个Bug需要10 minutes，拖到集成测试或者系统测试后，这个时间就可能是1 hour或者 1 day 或者更多时间，这里可不是'耸人听闻'，的确有真实的事例，有过这样的经历的人都体会到其中的痛苦。
痛定思痛，自己终于觉醒了。恰好，一个新的短期项目刚刚处于开发阶段，正好是发挥单元测试的大好时机。杀开一条血路，做就是了。但是不能盲目去做。单元测试是需要设计的，而且感觉单元测试设计因系统架构模式而异，有难有易;而且单元测试设计时需要考虑项目进度、测粒度和测试密度。测试粒度，也就是说你选择多大的功能单元来作为单元测试的基本单元，是函数一级的还是模块一级的;测试密度，则是你的单元测试用例的语句覆盖度有多少了。完美的单元测试是应该覆盖程序运行的每条分支的，但是要编写出这么多的单元测试用例，其工作量我想比开发这个系统的工作量只多不少，这样一来即使你能编写出这么多用例的代码，你的Leader也会对你吼的。选择关键路径覆盖是我的选择测试密度的'标准'。我们的系统的架构是基于'队列/管道架构模式'的，这也决定了我们的单元测试较容易，根据这个特点我选择我的单元测试的力度是模块一级的。基本策略就是根据模块内的关键路径设计模块级别的单元测试用例--对我们这个系统来说具体就是造各种各样的消息，放到输入队列中即可。
我的单元测试已经进行了两天多了，效果很是明显，有些bug的发现都出乎我的意料。每当测试完一个功能模块，我会感觉对这个模块更有信心了，还有一种莫名的成就感^_^。
好的单元测试最好是能自动化，这样一旦修改了代码，可以对以前测试过的代码进行回归单元测试，保证此次修改不影响到以前已经测试过的代码的正确性。不过自动化又谈何容易?Java有很好的工具支持，可谓众星捧月;C则是孤家寡人，少有有利的工具支持。这样的话，我们就需要自己写自动化的逻辑，当然这些逻辑因系统而异，至今我也很难想出好的通用的办法，比如像Mock Test这样的测试，在C中就很难实现，我们常常以真实的情景代之，而不是使用Mock，这样就可能让不同的用例对执行顺序有一个依赖，执行顺序不一致，测试的结果可能不相同。
以上的一些经验都有一定的语言局限性，对于使用C开发的系统可能有些借鉴的意义，但是对于Java开发的系统上面的很多说法也许还是误导的，大家一定要'睁大眼睛'，看清楚了^_^。单元测试仍在进行中...^_^
文章来源于领测软件测试网 https://www.ltesting.net/
