[ROR]TDD,想说爱你不容易
TDD,也就是 Test Driven Development--测试驱动开发,其实是一种开发方式的巨大提高。它 归根到底,TDD的实质仍然是以需求来驱动开发,只是,TDD中把需求进一步写成了测试,那 这么做的好处是什么?我想至少有以下这么几条: 1、你的代码是可测试的。 不错,我承认,TDD会带来成本的提高。因为我们要写测试,所以必然要花费时间。那么这部分 让老板买单?老板恐怕要为此付出加班费。舍得,还是舍不得?这似乎又变成了一个哲学的问 自己来买单?也就是自己白加班来做这些事。值得,还是不值得?这似乎又是一个职业态度的 如果单从理论上,每种买单方式都可以写厚厚的文字去论证,不过这么做其实并没有很大的意 就说最近的两个项目。一个是公司的移植项目,从一个专有的framework移植到structs;另一个 移植项目的团队中一共有10个人。我使用了Selenium这个工具。但因为是移植的项目,所以 因为需要测试的内容非常多,所以,我的测试方法也是越写越多,其中不停的重构和修改,也 是的,最开始,我花的时间确实比别人多一点,多多少呢??一个测试方法,我相信我用10分 而且,我每次修改完一个功能,我可以运行全部的测试,这样,我就知道我的修改对以前的改动 一个月下来,我能运行的测试类有140多个,需要注意的是,我并非写了140个测试方法,因为 这样,每次系统改动的时候,我只要把这些测试全运行一次,就知道我负责的模块是不是有问 那么其他人呢?他们仍然在手动测试,每次一个更新,他们都要手动去测试每一个地方,而且 那么我来计算一下成本吧!就算我那140个测试方法都是单独的,每个方法我需要10分钟, 那么收益是多大呢?一个月后,我只需要20分钟就可以知道系统是不是存在错误,而他们却 再来说说那个国内的项目。那个项目我要求了使用TDD的方式,因为这是一个从零开始的项 根据经验,一个测试方法大概需要10-20分钟,到目前为止,大概完成了25%,一共有40个测试 我通过了2个实践的例子来说明TDD的优势,其实归根到底,TDD从开发方面,节省了我们的 但是,就是这么一点点的成本,或许是再稍微多一点的成本,让很多公司望而止步。很多人仍然 “我们修改了一个bug,但同时又创造了一个新的bug。”这个神话不是我们自己创造的吗? 我想TDD还有漫长的道路需要走下去,需要更多的时间来获得人们的认同,只是目前的情况, 如果你是一个准备购买软件的客户,那么你可以毫不犹豫地要求软件开发商使用TDD的方式, 如果你是一个老板,那么你应该立刻要求下属学习并实践TDD,如果客户不买单,那么你应该 如果你是一个开发人员,那么你应该立刻学习并实践TDD,如果你的客户和老板都不准备买 单,那么就自己买单。你应该相信,微小的付出,会换来更多的价值! (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |