单元测试之国内现状和想法

TDD的概念其实在国人中已经是深入人心了,仿佛一夜之间大家都TDD了,但是,

目前感觉在国内,象最基本的单元测试,在大家的实际应用中,其实还是存在不少疑惑

或者误区,甚至是不可调和的矛盾的,又或者目前存在的一些现状,下面列举下,希望大家踊跃发言:



1 程序员真正喜欢先写单元测试的其实不多

其实国内除了那些大中软件企业,比如CMMI或者XP做的很好的企业外,

真正能让程序员先写单元测试,再写代码的其实不多,有的企业,虽然看上去口口声声

推XP很久,但落实到单元测试这个环节上,很多都是走过场的.不少程序员觉得

任务大,时间赶,人手少,一接到任务就是先赶代码完成工作量了,这其实是很普遍的现象.

而且,绝大部分程序员从骨子里不喜欢写单元测试,这是事实



2 如何给程序员减压,但又能做好单元测试?

中小企业的程序员和项目经理,一般面对的都是压力大,任务重的项目,

如果作为项目经理的你,觉得测试组有人(有人就行了,多少倒不大重要),

不妨让测试组的人早点介入单元测试,又或者假如测试组的人起码能写点

代码,那其实更好,就分配测试组的人去写单元测试,这其实是很有好处的.

A 首先,可以让程序员和测试人员在动手写一个模块前,先让他们讨论这个模块

的单元测试策略,这样可以减轻程序员的负担

B 双方指定单元测试的框架流程,程序员不编写单元测试代码,但由于程序员参与了讨论,

因此心里会更清楚;由测试人员编写单元测试代码

C 程序员写完代码后,由测试人员编写的单元测试代码去对碰程序员的代码,得出相关的测试报告

好处是,职责分离了,测试组的人能提前介入,对以后的集成测试很有好处,而且可以让

测试人员写点测试代码,好让他们不闲着,有点成就感;而且程序员的负担减少了,虽然

程序员不写单元测试代码了&＃xff0c;但由于一开始跟测试人员在一起,会对测试流程熟悉,

对代码编写很有好处.

以上一点建议,只供参考