说到单元测试,这次负责的这个项目中这方面表现的很让我伤心。带得这几个成员都是有两年多的经验了,为什么连代码写完了都不知道要测试,更不要说单元测试了。
一天小X很牛B的发给我一封邮件,标题:考试王已经砌底OK。内容也是简单的两句话,还是“考试王已经砌底OK!!!!!!”一堆的“!”号还怕我看不见,还把邮件抄送给部门老大,表示他很厉害。看到有成员做完模块,当然是很高兴了,合入到工程中一测试,kao,只是简单的测试,就发现十来处BUG,而且还不包括操作方面的,我狂晕,这是什么程序啊,做为一个程序员,连最基本的程序写好之后要测试都不知道,更不要说做单元测试了。返回修改之后,给我发了第二个版本,我要吐血,我一测,发现的新BUG只比第一次少一个,一个小小的改动,竟然引出新的问题出来。唉,我不知道是深圳的环境这样,还是人的问题。当然这方面我也有责任,做功能开发过程中,没有对他们的代码进行检视。导致在最后才发现问题。
没多久小L也提供了他的代码,我发现小X的问题之后,还特意招集团队成员开个会说明这件事,结果测试一下他的功能,“不是我不明白,是世界变化快!”,也许是我老了吧,现在的软件是不需要测试的。当时只想说一句话:“TMD,什么狗屁!”,既然有十几处BUG,很多都是最基本的,只要稍微测试一下就能发现了。他是成员里面最拽的了,每次说什么,都要说:这个谁不知道。而且每次就他问题最多了。
发了堆牢骚,言归正传。要进行单元测试,模块化代码的能力要很强,能把代码分解成一个函数只做一件事。这样对于这个函数就可以专门对它做测试了,你写测试代码的时候就有的放矢了。CPPUnit/JUnit提供的测试柜架是个很好的东西,它把程序代码和测试代码分开来,不会出现像以前那样,在代码中添加好多用宏包含起来的测试代码,阅读和维护代码的时候造成很大的困难。
采用单元测试的时候,每添加一个特性点,就要加入一组针对这一特性的测试函数。这要求对类或是函数(文件)要熟悉。不然添加的测试函数会不全面,或者测试函数本身就是错的。再者对于修改了某一功能项/函数,要相应的去改它的测试代码,而且每做一次BUG修改,就要加入对这一BUG的针对性测试函数。而且要运行一遍测试代码,看这一改动有没影响到其它函数。当然做单元测试,可以只对比较特别的函数做测试,不然随着类成员函数的增加,测试代码增加的速度比代码本身还快。
做单元测试,其优点有:首先,在开发的时候,就对代码做针对性的测试,这样可以少出现问题,而且一出现就可以修改了,这可以省下好多调试时间,相信有好多程序员遇到就因为一个小小的问题,比如一个符号或一个数字,整整调试了一两天时间。写单元测试代码可以很早的把错误定位出来。其次,写程序最恐怖的就是修改BUG了,一不小心就会引入新的BUG,特别是对于代码写法不规范或者代码逻辑很乱的程序,就像这次项目组中的两位。
总结:在做项目时,如果有条件,就是时间充足(不然很多人会偷工减料),团队成员有一定的实力,就可以考虑采用单元测试。虽然说单元测试使用对于项目哪一方面都是有好处的,但是如果条件不足,就会事倍功半的。对于能力较强的程序员,要自己养成写测试代码的习惯。还有一条跟单元测试没什么关系的话题,在程序进行中,要抽出时间对成员的代码进行检视,问题越早发现越好。
一天小X很牛B的发给我一封邮件,标题:考试王已经砌底OK。内容也是简单的两句话,还是“考试王已经砌底OK!!!!!!”一堆的“!”号还怕我看不见,还把邮件抄送给部门老大,表示他很厉害。看到有成员做完模块,当然是很高兴了,合入到工程中一测试,kao,只是简单的测试,就发现十来处BUG,而且还不包括操作方面的,我狂晕,这是什么程序啊,做为一个程序员,连最基本的程序写好之后要测试都不知道,更不要说做单元测试了。返回修改之后,给我发了第二个版本,我要吐血,我一测,发现的新BUG只比第一次少一个,一个小小的改动,竟然引出新的问题出来。唉,我不知道是深圳的环境这样,还是人的问题。当然这方面我也有责任,做功能开发过程中,没有对他们的代码进行检视。导致在最后才发现问题。
没多久小L也提供了他的代码,我发现小X的问题之后,还特意招集团队成员开个会说明这件事,结果测试一下他的功能,“不是我不明白,是世界变化快!”,也许是我老了吧,现在的软件是不需要测试的。当时只想说一句话:“TMD,什么狗屁!”,既然有十几处BUG,很多都是最基本的,只要稍微测试一下就能发现了。他是成员里面最拽的了,每次说什么,都要说:这个谁不知道。而且每次就他问题最多了。
发了堆牢骚,言归正传。要进行单元测试,模块化代码的能力要很强,能把代码分解成一个函数只做一件事。这样对于这个函数就可以专门对它做测试了,你写测试代码的时候就有的放矢了。CPPUnit/JUnit提供的测试柜架是个很好的东西,它把程序代码和测试代码分开来,不会出现像以前那样,在代码中添加好多用宏包含起来的测试代码,阅读和维护代码的时候造成很大的困难。
采用单元测试的时候,每添加一个特性点,就要加入一组针对这一特性的测试函数。这要求对类或是函数(文件)要熟悉。不然添加的测试函数会不全面,或者测试函数本身就是错的。再者对于修改了某一功能项/函数,要相应的去改它的测试代码,而且每做一次BUG修改,就要加入对这一BUG的针对性测试函数。而且要运行一遍测试代码,看这一改动有没影响到其它函数。当然做单元测试,可以只对比较特别的函数做测试,不然随着类成员函数的增加,测试代码增加的速度比代码本身还快。
做单元测试,其优点有:首先,在开发的时候,就对代码做针对性的测试,这样可以少出现问题,而且一出现就可以修改了,这可以省下好多调试时间,相信有好多程序员遇到就因为一个小小的问题,比如一个符号或一个数字,整整调试了一两天时间。写单元测试代码可以很早的把错误定位出来。其次,写程序最恐怖的就是修改BUG了,一不小心就会引入新的BUG,特别是对于代码写法不规范或者代码逻辑很乱的程序,就像这次项目组中的两位。
总结:在做项目时,如果有条件,就是时间充足(不然很多人会偷工减料),团队成员有一定的实力,就可以考虑采用单元测试。虽然说单元测试使用对于项目哪一方面都是有好处的,但是如果条件不足,就会事倍功半的。对于能力较强的程序员,要自己养成写测试代码的习惯。还有一条跟单元测试没什么关系的话题,在程序进行中,要抽出时间对成员的代码进行检视,问题越早发现越好。