<p style="text-indent: 21pt;">近来特别关注单元测试的应用。大家可能会笑了,单元测试都N年前提出的了,您老怎么现在才来做呢。是的,单元测试几乎人人都在提,但是真正做好的没几个。</p>
<p style="text-indent: 21pt;">我们几个同事在讨论这个的时候,发现这里面有很多因素。相信大家也在实践过程中都遇到过。</p>
<h3>单元测试测什么</h3>
<p style="text-indent: 21pt;">这是最经常被提到的问题。往往有三个答案:</p>
<ol>
<li>
<div style="text-indent: 21pt;">针对代码测试,往往也被称为针对类进行测试。</div>
</li>
<li>
<div style="text-indent: 21pt;">针对模块接口进行测试。这种模块往往是没有界面性质的。</div>
</li>
<li>
<div style="text-indent: 21pt;">针对业务功能进行测试。类似于模拟需求测试。</div>
</li>
</ol>
<p style="text-indent: 21pt;">在回答这个问题之前,我们都回顾一下,《测试驱动开发》中,强调的是Story的概念。Story就是一个应用场景。用程序的语言的来翻译的话,就是将需求实例化。</p>
<p style="text-indent: 21pt;">但是KENT BECK显然没有将这个概念明确化。这样难怪,业务模型,是基于不同层次来说的。如果你只是设计一个类,那么这个类本身也是有需求的。那么这个类的需求和整个软件的需求是不是一致对待呢?</p>
<p style="text-indent: 21pt;">个人倾向于第三类的测试,一二为补充。</p>
<p style="text-indent: 21pt;">不过这里重点说一下业务功能的测试难点,那就是模态窗体的测试。这个难点的罪魁祸首是Windows的消息机制决定的。每一个模态窗体都有自己的消息循环(死循环)在处理消息,当从一个模态窗体切换到另一个模态窗体的时候,测试代码就不能继续下去。</p>
<p style="text-indent: 21pt;">针对这个问题,我的处理方式,就是“解铃还须系铃人”。通过Windows的消息循环就可以穿透这种切换的休克。当然了,处理方式还是比较复杂的。</p>
<h3>单元测试代码不能工作了</h3>
<p style="text-indent: 21pt;">这往往是单元测试不能继续的借口。应该说,很多人还是热衷于进行单元测试的。可是你在后期询问单元测试的作用的时候,他们就会非常遗憾地告诉你,由于需求变更太频繁,单元测试代码已经不能工作了。</p>
<p style="text-indent: 21pt;">如果你有相似经验,你会非常赞同这个原因。因为,毕竟单元测试侧重的是软件质量,可是我们往往直接面对的是软件进度。没有人会告诉你面对质量和进度,应该选择什么。但是你知道,你只有选择进度。</p>
<p style="text-indent: 21pt;">几乎所有的程序员都能明白,前期的质量,会节省后期的进度。但是好像老板不知道。至少,很多程序员都相信这点。</p>
<p style="text-indent: 21pt;">不管怎么说,单元测试代码真的就这么放弃了吗?其实很简单,在你的考核体系中,加上单元测试代码失败的惩罚。因为选择一个技术,只是一个决策问题。而保障一个技术,那就是管理问题了。</p>
<p style="text-indent: 21pt;">不过,要注意的是,永远忘记单元测试必须时刻进行运行。每一次代码签入的时候,必须运行一次。必须认识到,有了这个自动机制,才能保障你的单元测试持续工作下去。</p>
<h3>单元测试需要设计</h3>
<p style="text-indent: 21pt;">非常多的人都认为,一个系统如果不针对单元测试进行设计,那么其可测试性就会降低,以至于不可以继续下去。</p>
<p style="text-indent: 21pt;">我并不怀疑设计的必要性,但这个说法最让我不得不怀疑另一个看上去毫不相干的观点:尝试和执行单元测试,需要的是勇气和决心。</p>
<p style="text-indent: 21pt;">这点其实KENT BECK在XP开发方式的介绍中,就说明了这个问题。作为执行的主体,人的性格很可能影响最终执行结果。</p>
<h3>小结</h3>
<p style="text-indent: 21pt;">软件工程中有很多新的工具,但我们往往发现叫好不叫座,而原因往往也是使用中国的一句古话就是:具体问题具体分析。但是回过头来分析一下,其实很多具体问题都是可以有办法解决的。将这些总结贡献出来,希望我们中国的软件技术走得更快点。</p>
<p style="text-indent: 21pt;">我们几个同事在讨论这个的时候,发现这里面有很多因素。相信大家也在实践过程中都遇到过。</p>
<h3>单元测试测什么</h3>
<p style="text-indent: 21pt;">这是最经常被提到的问题。往往有三个答案:</p>
<ol>
<li>
<div style="text-indent: 21pt;">针对代码测试,往往也被称为针对类进行测试。</div>
</li>
<li>
<div style="text-indent: 21pt;">针对模块接口进行测试。这种模块往往是没有界面性质的。</div>
</li>
<li>
<div style="text-indent: 21pt;">针对业务功能进行测试。类似于模拟需求测试。</div>
</li>
</ol>
<p style="text-indent: 21pt;">在回答这个问题之前,我们都回顾一下,《测试驱动开发》中,强调的是Story的概念。Story就是一个应用场景。用程序的语言的来翻译的话,就是将需求实例化。</p>
<p style="text-indent: 21pt;">但是KENT BECK显然没有将这个概念明确化。这样难怪,业务模型,是基于不同层次来说的。如果你只是设计一个类,那么这个类本身也是有需求的。那么这个类的需求和整个软件的需求是不是一致对待呢?</p>
<p style="text-indent: 21pt;">个人倾向于第三类的测试,一二为补充。</p>
<p style="text-indent: 21pt;">不过这里重点说一下业务功能的测试难点,那就是模态窗体的测试。这个难点的罪魁祸首是Windows的消息机制决定的。每一个模态窗体都有自己的消息循环(死循环)在处理消息,当从一个模态窗体切换到另一个模态窗体的时候,测试代码就不能继续下去。</p>
<p style="text-indent: 21pt;">针对这个问题,我的处理方式,就是“解铃还须系铃人”。通过Windows的消息循环就可以穿透这种切换的休克。当然了,处理方式还是比较复杂的。</p>
<h3>单元测试代码不能工作了</h3>
<p style="text-indent: 21pt;">这往往是单元测试不能继续的借口。应该说,很多人还是热衷于进行单元测试的。可是你在后期询问单元测试的作用的时候,他们就会非常遗憾地告诉你,由于需求变更太频繁,单元测试代码已经不能工作了。</p>
<p style="text-indent: 21pt;">如果你有相似经验,你会非常赞同这个原因。因为,毕竟单元测试侧重的是软件质量,可是我们往往直接面对的是软件进度。没有人会告诉你面对质量和进度,应该选择什么。但是你知道,你只有选择进度。</p>
<p style="text-indent: 21pt;">几乎所有的程序员都能明白,前期的质量,会节省后期的进度。但是好像老板不知道。至少,很多程序员都相信这点。</p>
<p style="text-indent: 21pt;">不管怎么说,单元测试代码真的就这么放弃了吗?其实很简单,在你的考核体系中,加上单元测试代码失败的惩罚。因为选择一个技术,只是一个决策问题。而保障一个技术,那就是管理问题了。</p>
<p style="text-indent: 21pt;">不过,要注意的是,永远忘记单元测试必须时刻进行运行。每一次代码签入的时候,必须运行一次。必须认识到,有了这个自动机制,才能保障你的单元测试持续工作下去。</p>
<h3>单元测试需要设计</h3>
<p style="text-indent: 21pt;">非常多的人都认为,一个系统如果不针对单元测试进行设计,那么其可测试性就会降低,以至于不可以继续下去。</p>
<p style="text-indent: 21pt;">我并不怀疑设计的必要性,但这个说法最让我不得不怀疑另一个看上去毫不相干的观点:尝试和执行单元测试,需要的是勇气和决心。</p>
<p style="text-indent: 21pt;">这点其实KENT BECK在XP开发方式的介绍中,就说明了这个问题。作为执行的主体,人的性格很可能影响最终执行结果。</p>
<h3>小结</h3>
<p style="text-indent: 21pt;">软件工程中有很多新的工具,但我们往往发现叫好不叫座,而原因往往也是使用中国的一句古话就是:具体问题具体分析。但是回过头来分析一下,其实很多具体问题都是可以有办法解决的。将这些总结贡献出来,希望我们中国的软件技术走得更快点。</p>