TDD,也就是 Test Driven Development--测试驱动开发,其实是一种开发方式的巨大提高。它
提出了一种新的开发方式:以测试为驱动。在此,我仍然想引用一个曾经看过的ThoughtWorks的
一个人的Blog中的一句话:“什么是TDD?TDD就是把你的需求用测试给描述出来。”这句话一下
子让我明白了TDD的意义,并且被我个人奉为TDD中的经典 :)
归根到底,TDD的实质仍然是以需求来驱动开发,只是,TDD中把需求进一步写成了测试,那
就成了测试驱动开发了。
这么做的好处是什么?我想至少有以下这么几条:
1、你的代码是可测试的。
2、你的代码完全反应了需求。
3、通过测试驱动,会规范你的代码和结构,甚至架构。
不错,我承认,TDD会带来成本的提高。因为我们要写测试,所以必然要花费时间。那么这部分
的成本谁来买单呢?客户吗?这很难,因为毕竟大部分的客户已经在软件的本身就和你讨价还价
了,你还想让客户再为测试来买单?
让老板买单?老板恐怕要为此付出加班费。舍得,还是舍不得?这似乎又变成了一个哲学的问
题。
自己来买单?也就是自己白加班来做这些事。值得,还是不值得?这似乎又是一个职业态度的
问题。
如果单从理论上,每种买单方式都可以写厚厚的文字去论证,不过这么做其实并没有很大的意
义,我还是从实践中说起。
就说最近的两个项目。一个是公司的移植项目,从一个专有的framework移植到structs;另一个
是我帮助朋友做的一个国内的小项目。第一个项目,我说了不算;第二个项目,我的意见起主导
作用。
移植项目的团队中一共有10个人。我使用了Selenium这个工具。但因为是移植的项目,所以
TDD的概念也就无从谈起。不过,每移植一个功能之前,我都是先按照旧系统的操作,使用
Selenium来编写测试类。在功能移植完毕之后,我在新系统中去跑我的测试类。
因为需要测试的内容非常多,所以,我的测试方法也是越写越多,其中不停的重构和修改,也
总结了一些简单的测试方式。
是的,最开始,我花的时间确实比别人多一点,多多少呢??一个测试方法,我相信我用10分
钟就足够写好了。重构?我想1,2个小时足够了。
而且,我每次修改完一个功能,我可以运行全部的测试,这样,我就知道我的修改对以前的改动
是不是造成了负面的影响。
一个月下来,我能运行的测试类有140多个,需要注意的是,我并非写了140个测试方法,因为
有的测试类是通过继承来实现的,这是因为有许多画面,可能就是商品种类不同,剩下的都相同。
这样,每次系统改动的时候,我只要把这些测试全运行一次,就知道我负责的模块是不是有问
题。
那么其他人呢?他们仍然在手动测试,每次一个更新,他们都要手动去测试每一个地方,而且
不能保证测试到了每一个地方。
那么我来计算一下成本吧!就算我那140个测试方法都是单独的,每个方法我需要10分钟,
那么我需要 1400 分钟,1400/60 = 23.3 个小时。也就是说,一个月下来,我只需要多付出23.3个
小时。
那么收益是多大呢?一个月后,我只需要20分钟就可以知道系统是不是存在错误,而他们却
需要几个小时,而且未必准确。
再来说说那个国内的项目。那个项目我要求了使用TDD的方式,因为这是一个从零开始的项
目。在实现一个功能之前,首先编写测试方法,确定了这个功能要实现什么目标,如果有错误,
该提示什么样的错误信息。
根据经验,一个测试方法大概需要10-20分钟,到目前为止,大概完成了25%,一共有40个测试
方法,那么成本就是 400/60 = 6.7 个小时。收益呢?目前只要做了任何一个改动,只要跑一遍测
试,就可以知道系统是不是存在问题。
我通过了2个实践的例子来说明TDD的优势,其实归根到底,TDD从开发方面,节省了我们的
测试资源,从用户方面,保证了产品的质量,从老板的角度来说,其实是用小的成本换来大的收
益---为什么这么说?小的成本其实就是测试方法的编写,大的收益就是产品质量的保证,以及更
好的产品,吸引来更多的客户。
但是,就是这么一点点的成本,或许是再稍微多一点的成本,让很多公司望而止步。很多人仍然
认为这些成本可以省掉。因为理由很充分:你看那么多公司,不是仍然效益很好,顾客很满意吗?
其实如果深入到那些公司内,就会发现:维护的项目是多么的糟糕,每次Release,如何保证这次
的改动不会造成影响?除了让QA的人测试大量的case,还有别的办法吗?
“我们修改了一个bug,但同时又创造了一个新的bug。”这个神话不是我们自己创造的吗?
我想TDD还有漫长的道路需要走下去,需要更多的时间来获得人们的认同,只是目前的情况,
只能是TDD,想说爱你不容易!
如果你是一个准备购买软件的客户,那么你可以毫不犹豫地要求软件开发商使用TDD的方式,
因为你应该知道这样做其实是在保护你的利益。
如果你是一个老板,那么你应该立刻要求下属学习并实践TDD,如果客户不买单,那么你应该
买单,因为你应该相信,微小的成本会换来更好的软件,更好的软件会迎来更多的客户。
如果你是一个开发人员,那么你应该立刻学习并实践TDD,如果你的客户和老板都不准备买
单,那么就自己买单。你应该相信,微小的付出,会换来更多的价值!
分享到:
相关推荐
测试驱动开发(Test-Driven Development,简称TDD)是一种软件开发方法,强调在编写实际功能代码之前,先编写测试用例。这种方法的核心理念是“先写测试,再写代码”。TDD通过引入测试来引导软件设计,使得开发过程...
6. **NAS层**:NAS(Non-Access Stratum)层涉及用户身份认证、位置更新等功能,在UMTS-TDD仿真中也是不可或缺的一部分。 ##### 关键技术点 1. **时间分隔技术**:TDD模式下,上行和下行数据传输通过时间分割来...
### 使用PHPUnit进行TDD驱动开发 #### 一、引言 测试驱动开发(TDD, Test-Driven Development)是一种软件开发方法论,它要求在编写实际功能代码之前先编写测试用例。通过这种方式,可以确保代码的质量,并且有助...
《Test Driven: Practical TDD and Acceptance TDD for Java Developers》是一本专注于Java开发者进行测试驱动开发(TDD)和验收测试驱动开发(Acceptance TDD)的专业书籍。这本书以PDF英文版的形式提供,旨在帮助...
### TDD读书报告知识点梳理 #### 一、了解和认识TDD - **定义**: 测试驱动开发(Test-Driven Development, TDD)是一种软件...随着更多企业和开发者对其深入理解和应用,TDD有望成为软件开发领域中不可或缺的一部分。
对于新人来说,阅读测试用例往往比阅读代码更容易理解系统的行为。 在“Test Driven Development in Action”这个实战教程中,你将学习如何设置测试环境,编写有效的测试用例,以及如何在Ruby项目中有效地应用TDD。...
"GSM TDD 噪声分析" GSM TDD 噪声是一种常见的干扰现象,发生在 GSM 通信系统中的射频部分。这种噪声的产生是由于天线辐射出的射频能量和 PA 突发工作时带动电源的干扰。为了减少这种噪声的影响,我们可以采用一些...
"TDD测试驱动开发.pptx" TDD 测试驱动开发是一种软件开发方法,它强调通过编写自动化测试来驱动整个开发过程。TDD 是敏捷开发中的一个核心实践和技术,也是一种设计方法论。其主要包括两方面:测试先行和代码重构。...
TDD不仅仅局限于特定的编程语言或技术栈,它的原则和实践可以在任何开发环境中应用。无论是在Java、Python还是其他任何语言中开发软件,TDD都能够帮助提高代码质量和开发效率,确保软件的稳定性和可维护性。 #### ...
【Laravel开发-TDD(测试驱动开发)】 在软件开发领域,TDD(Test-Driven Development,测试驱动开发)是一种编程实践,它强调先编写测试用例,再编写实现功能的代码。Laravel,作为一款流行的PHP框架,高度支持TDD...
此外,TDD不仅仅是一种技术实践,还是一种思维方式的转变。它要求开发者始终保持对代码质量的关注,通过持续的测试来驱动设计,从而提高软件的可靠性。通过阅读《测试驱动开发的艺术》,开发者将能够更好地理解和...
### 嵌入式TDD:测试驱动开发在嵌入式C中的应用 #### 引言 测试驱动开发(Test-Driven Development,简称TDD)是一种软件开发方法论,其核心理念是在编写实际代码之前先编写测试用例。这种方法不仅有助于确保代码...
管理测试资产也是TDD实践中不可忽视的一部分。测试资产包括测试用例、测试脚本、测试数据等,这些都应当得到良好的组织和维护,以便在软件开发的全生命周期内重复使用。 在敏捷开发中,测试类型主要分为单元测试、...
4. **重构代码**:在不破坏现有功能的前提下优化代码结构或设计。 5. **重复以上步骤**:直到完成所有需求。 #### 三、《TDD by Example》书籍概述 **《TDD by Example》** 是由 Kent Beck 所著的一本关于测试驱动...
- **过度设计**:如果不加节制,TDD可能导致过度设计,增加不必要的复杂性。 - **时间投入**:初期可能会感觉TDD增加了开发时间,但长期来看,它可以节省调试和维护的时间。 5. **工具支持** 在Java中,JUnit是...