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

TDD的概念其实在国人中已经是深入人心了,仿佛一夜之间大家都TDD了,但是,
目前感觉在国内,象最基本的单元测试,在大家的实际应用中,其实还是存在不少疑惑
或者误区,甚至是不可调和的矛盾的,又或者目前存在的一些现状,下面列举下,希望大家踊跃发言:

1 程序员真正喜欢先写单元测试的其实不多
   其实国内除了那些大中软件企业,比如CMMI或者XP做的很好的企业外,
真正能让程序员先写单元测试,再写代码的其实不多,有的企业,虽然看上去口口声声
推XP很久,但落实到单元测试这个环节上,很多都是走过场的.不少程序员觉得
任务大,时间赶,人手少,一接到任务就是先赶代码完成工作量了,这其实是很普遍的现象.
而且,绝大部分程序员从骨子里不喜欢写单元测试,这是事实

2 如何给程序员减压,但又能做好单元测试?
  中小企业的程序员和项目经理,一般面对的都是压力大,任务重的项目,
如果作为项目经理的你,觉得测试组有人(有人就行了,多少倒不大重要),
不妨让测试组的人早点介入单元测试,又或者假如测试组的人起码能写点
代码,那其实更好,就分配测试组的人去写单元测试,这其实是很有好处的.
  A 首先,可以让程序员和测试人员在动手写一个模块前,先让他们讨论这个模块
的单元测试策略,这样可以减轻程序员的负担
  B 双方指定单元测试的框架流程,程序员不编写单元测试代码,但由于程序员参与了讨论,
因此心里会更清楚;由测试人员编写单元测试代码
  C 程序员写完代码后,由测试人员编写的单元测试代码去对碰程序员的代码,得出相关的测试报告
   好处是,职责分离了,测试组的人能提前介入,对以后的集成测试很有好处,而且可以让
测试人员写点测试代码,好让他们不闲着,有点成就感;而且程序员的负担减少了,虽然
程序员不写单元测试代码了，但由于一开始跟测试人员在一起,会对测试流程熟悉,
对代码编写很有好处.
  以上一点建议,只供参考

评论

1 楼 houxinyou 2011-03-09  

感觉最关键的问题在于业务根本都确定不下来,好多时候都是客户不知道自己要什么,你把东西完成后客户挑毛病再改!
客户不会看了你的测试就知道是不是他要的.
这种情况决定了不可能先写测试再写实现.如果只写实现,那么客户要求改时只改实现代码,如果是先写单元测试,那么改程序的时候要改两份代码!