2006-09-05
你能说服你的同事写单元测试吗?
关键字: agile
我把单元测试的好处都阐述了一遍,可是大家仍然有很多疑虑,其中最主要的是担心写测试会降低开发效率——写测试代码+写功能代码〉〉写功能代码
最终由于这个项目工期很紧,否决了我的建议!
daquan198163 2006-09-28 18:13
根据自己三年多来的开发经历谈些感受:
我觉得最大的阻力还是来自程序员自身
管理层一般不会关心开发方法和技术细节的问题
struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧
毕竟这牵涉到他的切身利益(工作效率、成就感、乐趣。。。)
同样的道理,单元测试和其他敏捷方法也要首先打动技术人员的心,然后想不流行都难
目前的情况与这两种技术本身的特点也有关,单元测试是阳春白雪,struts是下里巴人
我自己的经历就是这样:03年中时,我们经理让我研究一下junit和eclipse
那时候我用struts和jbuilder用的正爽,瞟了一眼觉得eclipse太简陋了(其实是自己被jb这种傻瓜相机惯坏了)
junit就更无法接受,那时觉得程序员写业务代码天经地义,写测试就是自虐
于是就丢在一边不再看了(可是如今,这两样东西已经是我工作中最重要的工具了)
daquan198163 2006-09-28 18:48
每次看到缺少测试的代码以及还在不停制造这种代码的程序员,我就会感叹前几年走的弯路:
04年我经历了一个项目,20人在客户现场开发,开发到后期时,整个项目就像一座沙子堆起的城堡,稍有不慎就会跨塌
于是,程序员们开始变得消极、焦虑、易怒、神经质。。。。(更年期?? )
消极体现在:不愿意修改bug,不愿意改代码以满足用户新的需求
焦虑:担心刚刚修改的代码会破坏已有功能,对下一个版本能否正常工作毫无信心,梦到测试人员发现其大量bug
易怒:经常对测试mm发火,私下里诅咒客户,抱怨别人弄坏了自己的程序
神经质:系统偶尔出现奇怪行为就胡乱猜测,改了不该改的地方导致更多奇怪现象出现
那段日子简直不堪回首,是对程序员身心的双重折磨
daquan198163 2006-09-28 19:06
自从单元测试(连带着轻量级架构和敏捷)走进我的世界,我发现我变得快乐了
编成不再是一件痛苦的事——至少不那么痛苦了——反而增添了很多乐趣和满足感
勇气:单元测试是自动化的回归测试,她让我对自己的代码充满自信,每一个测试就像攀岩者钉在峭壁上的一个楔子,没有了程序衰退的担心,于是我可以大胆的重构、积极的拥抱变化;
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、部署、重起server以及在一堆日志里找结果的工作,开发的效率极大提高;
测试驱动设计:通过编写测试可以准确的理解需求、发现问题、发现接口,在不知不觉间做出最合理的设计;
文档:测试是最好的详细设计文档,不会过时、可运行。
daquan198163 2006-09-28 19:31
前面我提到,很多人最主要的是担心写测试会降低开发效率——写测试代码时间+写功能代码时间〉〉写功能代码时间
对于这个问题,论坛里以前有人讨论过了,marting也说明过,大致的意思是:如果软件开发的主要工作是敲键盘的话,那个命题是成立的。
事实大家都知道,这个时间只占很小比例,但毕竟也是多用了,那么在哪儿又节省了呢,答案就是快速反馈。
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、重新部署以及在一堆日志里找结果的工作;
写测试3+写代码3+跑测试看结果1=7
写代码3+打包2+重新部署10+用ie访问程序2+在一堆日志里找结果并确认5=22
我一点也没夸张,那个was5重新部署一次真的很慢,有时还需要重起服务
最终由于这个项目工期很紧,否决了我的建议!
daquan198163 2006-09-28 18:13
根据自己三年多来的开发经历谈些感受:
我觉得最大的阻力还是来自程序员自身
管理层一般不会关心开发方法和技术细节的问题
struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧
毕竟这牵涉到他的切身利益(工作效率、成就感、乐趣。。。)
同样的道理,单元测试和其他敏捷方法也要首先打动技术人员的心,然后想不流行都难
目前的情况与这两种技术本身的特点也有关,单元测试是阳春白雪,struts是下里巴人
我自己的经历就是这样:03年中时,我们经理让我研究一下junit和eclipse
那时候我用struts和jbuilder用的正爽,瞟了一眼觉得eclipse太简陋了(其实是自己被jb这种傻瓜相机惯坏了)
junit就更无法接受,那时觉得程序员写业务代码天经地义,写测试就是自虐
于是就丢在一边不再看了(可是如今,这两样东西已经是我工作中最重要的工具了)
daquan198163 2006-09-28 18:48
每次看到缺少测试的代码以及还在不停制造这种代码的程序员,我就会感叹前几年走的弯路:
04年我经历了一个项目,20人在客户现场开发,开发到后期时,整个项目就像一座沙子堆起的城堡,稍有不慎就会跨塌
于是,程序员们开始变得消极、焦虑、易怒、神经质。。。。(更年期?? )
消极体现在:不愿意修改bug,不愿意改代码以满足用户新的需求
焦虑:担心刚刚修改的代码会破坏已有功能,对下一个版本能否正常工作毫无信心,梦到测试人员发现其大量bug
易怒:经常对测试mm发火,私下里诅咒客户,抱怨别人弄坏了自己的程序
神经质:系统偶尔出现奇怪行为就胡乱猜测,改了不该改的地方导致更多奇怪现象出现
那段日子简直不堪回首,是对程序员身心的双重折磨
daquan198163 2006-09-28 19:06
自从单元测试(连带着轻量级架构和敏捷)走进我的世界,我发现我变得快乐了
编成不再是一件痛苦的事——至少不那么痛苦了——反而增添了很多乐趣和满足感
勇气:单元测试是自动化的回归测试,她让我对自己的代码充满自信,每一个测试就像攀岩者钉在峭壁上的一个楔子,没有了程序衰退的担心,于是我可以大胆的重构、积极的拥抱变化;
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、部署、重起server以及在一堆日志里找结果的工作,开发的效率极大提高;
测试驱动设计:通过编写测试可以准确的理解需求、发现问题、发现接口,在不知不觉间做出最合理的设计;
文档:测试是最好的详细设计文档,不会过时、可运行。
daquan198163 2006-09-28 19:31
前面我提到,很多人最主要的是担心写测试会降低开发效率——写测试代码时间+写功能代码时间〉〉写功能代码时间
对于这个问题,论坛里以前有人讨论过了,marting也说明过,大致的意思是:如果软件开发的主要工作是敲键盘的话,那个命题是成立的。
事实大家都知道,这个时间只占很小比例,但毕竟也是多用了,那么在哪儿又节省了呢,答案就是快速反馈。
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、重新部署以及在一堆日志里找结果的工作;
写测试3+写代码3+跑测试看结果1=7
写代码3+打包2+重新部署10+用ie访问程序2+在一堆日志里找结果并确认5=22
我一点也没夸张,那个was5重新部署一次真的很慢,有时还需要重起服务
评论
daquan198163
2006-10-11
yinjia11 写道
个人认为单元测试还是很必要的.说起来有些惭愧,刚开始写代码的时候,可能是比较紧张还是什么,经常犯一些低级错误,什么大小写写错了,单词拼写错误等等,跑junit测试的时候看见报的那些错误脸都红了.我们公司是领导下命令一定要写单元测试用例的.
不过单元测试也有一点很麻烦的就是,在需求从一开始就确定的情况下,单元测试对程序的保证非常必要.但是一旦后期业务发生改变,对象或增加字段或减少字段,就要牵涉的单元测试的改动.虽然说这个确实是非常有必要的,但是,因为很多时候并不是牵连到一个单元测试的改动,改动起来就非常头痛了,感觉就像在汪洋大海中去捞你要改的那颗针,改起来怨声一片.所以现在公司的同事虽然初期都写了测试用例,不过后来业务需求发生改变的时候基本已经没有管测试用例了.
不过单元测试也有一点很麻烦的就是,在需求从一开始就确定的情况下,单元测试对程序的保证非常必要.但是一旦后期业务发生改变,对象或增加字段或减少字段,就要牵涉的单元测试的改动.虽然说这个确实是非常有必要的,但是,因为很多时候并不是牵连到一个单元测试的改动,改动起来就非常头痛了,感觉就像在汪洋大海中去捞你要改的那颗针,改起来怨声一片.所以现在公司的同事虽然初期都写了测试用例,不过后来业务需求发生改变的时候基本已经没有管测试用例了.
如果不能保证测试用例与代码的一致,其好处就会大打折扣。
在敏捷开发中,测试代码是头等公民,要像维护功能代码一样来维护。
就好比攀岩时为了加快速度而省略了钉岩钉的工作,会让你爬得越高摔得越惨。
虽然麻烦一些,但想想这样做的好处也就释然了
yinjia11
2006-10-11
个人认为单元测试还是很必要的.说起来有些惭愧,刚开始写代码的时候,可能是比较紧张还是什么,经常犯一些低级错误,什么大小写写错了,单词拼写错误等等,跑junit测试的时候看见报的那些错误脸都红了.我们公司是领导下命令一定要写单元测试用例的.
不过单元测试也有一点很麻烦的就是,在需求从一开始就确定的情况下,单元测试对程序的保证非常必要.但是一旦后期业务发生改变,对象或增加字段或减少字段,就要牵涉的单元测试的改动.虽然说这个确实是非常有必要的,但是,因为很多时候并不是牵连到一个单元测试的改动,改动起来就非常头痛了,感觉就像在汪洋大海中去捞你要改的那颗针,改起来怨声一片.所以现在公司的同事虽然初期都写了测试用例,不过后来业务需求发生改变的时候基本已经没有管测试用例了.
不过单元测试也有一点很麻烦的就是,在需求从一开始就确定的情况下,单元测试对程序的保证非常必要.但是一旦后期业务发生改变,对象或增加字段或减少字段,就要牵涉的单元测试的改动.虽然说这个确实是非常有必要的,但是,因为很多时候并不是牵连到一个单元测试的改动,改动起来就非常头痛了,感觉就像在汪洋大海中去捞你要改的那颗针,改起来怨声一片.所以现在公司的同事虽然初期都写了测试用例,不过后来业务需求发生改变的时候基本已经没有管测试用例了.
daquan198163
2006-10-11
把我的一些回帖加到第一页了
zidoing
2006-10-09
有工作经验又不了解单元测试也不想了解单元测试的人是很难说服的。
抛出异常的爱
2006-10-06
单元测试之后ejb的开发效率提高300%以上一点也没有夸张
不过在推行时还有很多阻力。。。
不过在推行时还有很多阻力。。。
jack
2006-09-28
引用
daquan198163
用自身的经历说明了一个很明确的事实,没有完全搞清楚好与不好前。你连说服其他人的能力都没有的时候,还是不要去搞什么新技术推广。
从daquan198163第一次知道了单元测试的好在哪里?以前都是看到是否需要单元测试,也只是知道有单元测试而已。给你投5星
daquan198163
2006-09-28
前面我提到,很多人最主要的是担心写测试会降低开发效率——写测试代码时间+写功能代码时间〉〉写功能代码时间
对于这个问题,论坛里以前有人讨论过了,marting也说明过,大致的意思是:如果软件开发的主要工作是敲键盘的话,那个命题是成立的。
事实大家都知道,这个时间只占很小比例,但毕竟也是多用了,那么在哪儿又节省了呢,答案就是快速反馈。
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、重新部署以及在一堆日志里找结果的工作;
写测试3+写代码3+跑测试看结果1=7
写代码3+打包2+重新部署10+用ie访问程序2+在一堆日志里找结果并确认5=22
我一点也没夸张,那个was5重新部署一次真的很慢,有时还需要重起服务
对于这个问题,论坛里以前有人讨论过了,marting也说明过,大致的意思是:如果软件开发的主要工作是敲键盘的话,那个命题是成立的。
事实大家都知道,这个时间只占很小比例,但毕竟也是多用了,那么在哪儿又节省了呢,答案就是快速反馈。
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、重新部署以及在一堆日志里找结果的工作;
写测试3+写代码3+跑测试看结果1=7
写代码3+打包2+重新部署10+用ie访问程序2+在一堆日志里找结果并确认5=22
我一点也没夸张,那个was5重新部署一次真的很慢,有时还需要重起服务
daquan198163
2006-09-28
自从单元测试(连带着轻量级架构和敏捷)走进我的世界,我发现我变得快乐了
编成不再是一件痛苦的事——至少不那么痛苦了——反而增添了很多乐趣和满足感
勇气:单元测试是自动化的回归测试,她让我对自己的代码充满自信,每一个测试就像攀岩者钉在峭壁上的一个楔子,没有了程序衰退的担心,于是我可以大胆的重构、积极的拥抱变化;
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、部署、重起server以及在一堆日志里找结果的工作,开发的效率极大提高;
测试驱动设计:通过编写测试可以准确的理解需求、发现问题、发现接口,在不知不觉间做出最合理的设计;
文档:测试是最好的详细设计文档,不会过时、可运行。
编成不再是一件痛苦的事——至少不那么痛苦了——反而增添了很多乐趣和满足感
勇气:单元测试是自动化的回归测试,她让我对自己的代码充满自信,每一个测试就像攀岩者钉在峭壁上的一个楔子,没有了程序衰退的担心,于是我可以大胆的重构、积极的拥抱变化;
快速反馈:每写一段代码,我都可以在几秒钟之内看到他的运行效果,免去了打包、部署、重起server以及在一堆日志里找结果的工作,开发的效率极大提高;
测试驱动设计:通过编写测试可以准确的理解需求、发现问题、发现接口,在不知不觉间做出最合理的设计;
文档:测试是最好的详细设计文档,不会过时、可运行。
daquan198163
2006-09-28
每次看到缺少测试的代码以及还在不停制造这种代码的程序员,我就会感叹前几年走的弯路:
04年我经历了一个项目,20人在客户现场开发,开发到后期时,整个项目就像一座沙子堆起的城堡,稍有不慎就会跨塌
于是,程序员们开始变得消极、焦虑、易怒、神经质。。。。(更年期??
)
消极体现在:不愿意修改bug,不愿意改代码以满足用户新的需求
焦虑:担心刚刚修改的代码会破坏已有功能,对下一个版本能否正常工作毫无信心,梦到测试人员发现其大量bug
易怒:经常对测试mm发火,私下里诅咒客户,抱怨别人弄坏了自己的程序
神经质:系统偶尔出现奇怪行为就胡乱猜测,改了不该改的地方导致更多奇怪现象出现
那段日子简直不堪回首,是对程序员身心的双重折磨
04年我经历了一个项目,20人在客户现场开发,开发到后期时,整个项目就像一座沙子堆起的城堡,稍有不慎就会跨塌
于是,程序员们开始变得消极、焦虑、易怒、神经质。。。。(更年期??
消极体现在:不愿意修改bug,不愿意改代码以满足用户新的需求
焦虑:担心刚刚修改的代码会破坏已有功能,对下一个版本能否正常工作毫无信心,梦到测试人员发现其大量bug
易怒:经常对测试mm发火,私下里诅咒客户,抱怨别人弄坏了自己的程序
神经质:系统偶尔出现奇怪行为就胡乱猜测,改了不该改的地方导致更多奇怪现象出现
那段日子简直不堪回首,是对程序员身心的双重折磨
daquan198163
2006-09-28
根据自己三年多来的开发经历谈些感受:
我觉得最大的阻力还是来自程序员自身
管理层一般不会关心开发方法和技术细节的问题
struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧
毕竟这牵涉到他的切身利益(工作效率、成就感、乐趣。。。)
同样的道理,单元测试和其他敏捷方法也要首先打动技术人员的心,然后想不流行都难
目前的情况与这两种技术本身的特点也有关,单元测试是阳春白雪,struts是下里巴人
我自己的经历就是这样:03年中时,我们经理让我研究一下junit和eclipse
那时候我用struts和jbuilder用的正爽,瞟了一眼觉得eclipse太简陋了(其实是自己被jb这种傻瓜相机惯坏了)
junit就更无法接受,那时觉得程序员写业务代码天经地义,写测试就是自虐
于是就丢在一边不再看了(可是如今,这两样东西已经是我工作中最重要的工具了)
我觉得最大的阻力还是来自程序员自身
管理层一般不会关心开发方法和技术细节的问题
struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧
毕竟这牵涉到他的切身利益(工作效率、成就感、乐趣。。。)
同样的道理,单元测试和其他敏捷方法也要首先打动技术人员的心,然后想不流行都难
目前的情况与这两种技术本身的特点也有关,单元测试是阳春白雪,struts是下里巴人
我自己的经历就是这样:03年中时,我们经理让我研究一下junit和eclipse
那时候我用struts和jbuilder用的正爽,瞟了一眼觉得eclipse太简陋了(其实是自己被jb这种傻瓜相机惯坏了)
junit就更无法接受,那时觉得程序员写业务代码天经地义,写测试就是自虐
于是就丢在一边不再看了(可是如今,这两样东西已经是我工作中最重要的工具了)
抛出异常的爱
2006-09-28
听说好不一定真好
真好不一定能用的上
用的上不一定会对你有帮助
有帮助不一定没危险
没危险,有帮助,用的上,的才是好东西
听说好是没用的。。。。
测试先行开发(TDD)看了两个月书
试用了一个月后才将将算的上TDD
真好不一定能用的上
用的上不一定会对你有帮助
有帮助不一定没危险
没危险,有帮助,用的上,的才是好东西
听说好是没用的。。。。
测试先行开发(TDD)看了两个月书
试用了一个月后才将将算的上TDD
jack
2006-09-27
类似这种方法的推行有这么多麻烦吗?局部的个人实验,项目领导也会干预?
有些方法并非其他人不想推行,是想推行的人都搞不清楚流程,方法,和好处吧!
不能预见的风险是主要因素 的确是领导们最担心的。所以先从自己做起来,然后一切顺风顺水了。还怕没人用?
有些方法并非其他人不想推行,是想推行的人都搞不清楚流程,方法,和好处吧!
不能预见的风险是主要因素 的确是领导们最担心的。所以先从自己做起来,然后一切顺风顺水了。还怕没人用?
抛出异常的爱
2006-09-27
我想说的是不要倚靠领导
由于每个领导面临着的是进度压力
能稳定生产才是他们关心的
而不是效率。。。。。。
当一个新的框架出现很少有公司用
主要还是风险高。。。。
当所有的领导都了解了TDD时
其它先进的东西你要不要一起都要领导推行?
一点点变成XP开发?
答案100%是否定的
不能预见的风险是主要因素。。。。
由于每个领导面临着的是进度压力
能稳定生产才是他们关心的
而不是效率。。。。。。
当一个新的框架出现很少有公司用
主要还是风险高。。。。
当所有的领导都了解了TDD时
其它先进的东西你要不要一起都要领导推行?
一点点变成XP开发?
答案100%是否定的
不能预见的风险是主要因素。。。。
pesome
2006-09-27
抛出异常的爱 写道
pesome 写道
在中国很多事情还是靠权利(有个好的领导),我前面的项目就是先说服领导,然后把单元测试作为代码规范,这样后面就好推广的多。
坐等靠
都是靠不住的
每个人的自由度是多少
难到写个测试也要领导点头
推来推去一辈子都上不了
如果说老板用刀逼你去XP开发
你也XP不起来
只有有了目的性才能自我提高。。。
另外别人提不提高如果不是结对就跟本不要去管
那是个人的自由强迫不来的
说服领导!=坐等
很多领导其实都是开明的,关键你要让他明白单元测试不是浪费时间,而是为了提高效率。
对于其它程序员你要靠好的习惯影响他们,如果你是SA则有责任跟他们进行沟通。
不管如何,坚持自己做单元测试,同时逐渐真正理解测试,会junit并不等于就会测试。提高自己的素质和开发的效率就是给他人的最好例证。
抛出异常的爱
2006-09-27
pesome 写道
在中国很多事情还是靠权利(有个好的领导),我前面的项目就是先说服领导,然后把单元测试作为代码规范,这样后面就好推广的多。
坐等靠
都是靠不住的
每个人的自由度是多少
难到写个测试也要领导点头
推来推去一辈子都上不了
如果说老板用刀逼你去XP开发
你也XP不起来
只有有了目的性才能自我提高。。。
另外别人提不提高如果不是结对就跟本不要去管
那是个人的自由强迫不来的
pesome
2006-09-27
在中国很多事情还是靠权利(有个好的领导),我前面的项目就是先说服领导,然后把单元测试作为代码规范,这样后面就好推广的多。
抛出异常的爱
2006-09-27
没必要。。。。
用上之后效率就提高了
如果不让用我就偷偷的用
主要是框架研究时花时间很多
我一般是下班之后在家研究。。
用上之后效率就提高了
如果不让用我就偷偷的用
主要是框架研究时花时间很多
我一般是下班之后在家研究。。
adamzhao
2006-09-27
最难得恐怕是说服我的领导去推广单元测试。
还好我没有疯掉呢,
抛出异常的爱 写道
我的作法是让他去作EJB(项目中一小部分还在用)
每修改启动一次就要10分钟以上
精神力再强的人都会疯掉。。。
之后抛出鸦片。。。。
每修改启动一次就要10分钟以上
精神力再强的人都会疯掉。。。
之后抛出鸦片。。。。
还好我没有疯掉呢,
bigpanda
2006-09-26
Manning出的JUnit Recipes挺好的。
JavaInActoin
2006-09-26
单元测试终究是一种质量保证手段,是否需要单元测试,要视软件的质量要求而定。
要说服别人单元测试或TDD能提高效率,难度太大。
要说服别人单元测试或TDD能提高效率,难度太大。
- 浏览: 71835 次
- 性别:

- 来自: 吉林->北京->上海

- 详细资料
搜索本博客
我的相册
4939384202000irl_0
共 3 张
共 3 张
最新评论
-
如何为行驶中的汽车换轮子 ...
好像Spring可以的麻 不过也是局限于你的bean替换,而且是同一接口. 既 ...
-- by zxbyhcsdn -
都别装了,难道你们不想交 ...
。。。 写道感觉很多薪资外的因素也应该谈谈,比如说企业文化,成长空间等,不仅仅是 ...
-- by daquan198163 -
都别装了,难道你们不想交 ...
失衡,泪奔而过
-- by laiseeme -
都别装了,难道你们不想交 ...
感觉很多薪资外的因素也应该谈谈,比如说企业文化,成长空间等,不仅仅是简单的那么个 ...
-- by 。。。 -
都别装了,难道你们不想交 ...
广州|2006|开始工作|专科|目前职位:SE|股份|13薪税前5k| 项目 ...
-- by python






评论排行榜