前端之家收集整理的这篇文章主要介绍了
你能说服你的同事写单元测试吗?,
前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我把单元测试的好处都阐述了一遍,可是大家仍然有很多疑虑,其中最主要的是担心写测试会降低开发效率——写测试
代码+写
功能代码〉〉写
功能代码 最终由于这个项目工期很紧,否决了我的建议! 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重新部署一次真的很慢,有时还需要重起服务