测试驱动开发(TDD)基础知识


 测试驱动开发(TDD)基础知识

1. 测试驱动开发(Test-Driven Development):是敏捷开发中的一项核心实践和技术,也是一种设计方法论。是极限编程的一个重要组成部分,它的基本思想就是在开发功能代码之前,先编写测试代码。

2. TDD的原理:在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代理。

3. TDD基本思路:通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把 需求分析,设计,质量控制量化的过程。

4. TDD的重要目的:不仅仅是测试软件,测试工作保证代码质量仅仅是其中一部分,而且是在开发过程中帮助客户和程序员出去模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是变成测试用例框架对功能的过程和接口进行设计,而测试框架可以持续验证。

5. TDD优缺点:
  a.优点:(在任意一个开发点都可以拿出一个可以使用,含少量bug并具有一定功能的产品。)
  『充满吸引力的优点』
      ①完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了,而传统的方式很难知道什么时候编码工作结束了。
      ②全面正确的认识代码和利用代码,而传统的方式没有这个机会。
      ③为利用你成果的人提供Sample,无论它是要利用你的源代码,还是直接重用你提供的组件。
      ④开发小组间降低了交流成本,提高了相互信赖程度。
      ⑤避免了过渡设计。
      ⑥系统可以与详尽的测试集一起发布,从而对程序的将来版本的修改和扩展提供方便。
      ⑦TDD给了我们自信,让我们今天的问题今天解决,明天的问题明天解决,今天不能解决明天的问题,因为明天的问题还没有出现(没有TestCase),除非有TestCase否则我决不写任何代码;明天也不必担心今天的问题,只要我亮了绿灯。
     『不显而易见的优点』
      ①逃避了设计角色。对于一个敏捷的开发小组,每个人都在做设计。
      ②大部分时间代码处在高质量状态,100%的时间里成果是可见的。
是由于可以保证编写测试和编写代码的是相同的程序员,降低了理解代码所花费的成本。
      ③为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
      ④在预先设计和紧急设计之间建立一种平衡点,为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。
     『有争议的优点』
      ①事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点,但观望者则不同,不相信TDD的人甚至坚决反对这一点,这很正常,世界总是这样。
      ②发现比传统测试方式更多的Bug。
      ③使IDE的调试功能失去意义,或者应该说,避免了令人头痛的调试和节约了调试的时间。
      ④总是处在要么编程要么重构的状态下,不会使人抓狂。(两顶帽子)
      ⑤单元测试非常有趣。
  b.缺点:增加代码量。测试代码是系统代码的两倍或更多。

6. 测试驱动开发的效果:以可执行的形式文档化你的需求,迫使你分清职责隔离依赖以驱动你的设计,编织安全网以便将Bug扼杀在摇篮的状态,防止其逃逸。

7. 测试人员在新的特性还没开发完成之前做什么?
除了提前编写测试用例,而需要测试人员一起参加一项重要的活动,就是参与特性验收条件的制定。

8. 测试驱动开发的基本过程a. 快速新增一个测试用例              新的TestCase
b. 编译所有代码,刚刚写的那个测试很可能编译不通过                          原始的TODO List
c. 做尽可能少的改动,让编译通过                                              Interface
d. 运行所有的测试,发现最新的测试不能编译通过                         -(Red Bar)
e .做尽可能少的改动,让测试通过                                       Implementation
f. 运行所有的测试,保证每个都能通过                                    -(Green Bar)
g. 重构代码,以消除重复设计                                               Clean Code That Works

9. TDD与AMDD(敏捷模型驱动开发)相比
  ·TDD缩短了编程反馈周期,而AMDD缩短了建模反馈周期
  ·TDD提供详细规范(测试),而AMDD提供一般规范(数据模型)
  ·TDD有助易于开发中编写搞质量代码,而AMDD有助于在项目中桶项目负责人和开发人员进行有效地沟通
  ·TDD能对你开发的软件有一个具体形态描述,AMDD能让你的团队,包括项目负责人,向着一个共有的目标前进;
  ·TDD提供了具体的文档的具体反馈,而AMDD对具体文档的允许口头反馈(具体反馈需要程序员在代码中证明,而那样就是非敏捷模型的技术了)
  ·TDD可同构关注代码的调用和可测试来看你的设计是否整洁,而AMDD提供一个机会让你在写代码之前思考
  ·TDD是非可视化的,而AMDD是可视化的
  ·两种技术对传统开发人员来说都是新的,搞不好会让他们不爽
  ·两种结束都支持螺旋式开发

10.TDD = TFD (Test First Development ) + 重构
测试驱动的编程是 XP 困扰程序员的一个方面。对于测试驱动的编程意味着什么以及如何去做,大多数人都做出了不正确的假设。这个月,XP 方面的讲师兼 Java 开发人员 Roy Miller 谈论了测试驱动的编程是什么,它为什么可以使程序员的生产力和质量发生巨大变化,以及编写测试的原理。请在与本文相随的 论坛提出您就本文的想法,以飨笔者和其他读者。(您也可以单击本文顶部或底部的“讨论”来访问该论坛。) 最近 50 年来,测试一直被视为项目结束时要做的事。当然,可以在项目进行之结合测试测试通常并不是在 所有编码工作结束后才开始,而是一般在稍后阶段进行测试。然而,XP 的提倡者建议完全逆转这个模型。作为一名程序员,应该在编写代码 之前编写测试,然后只编写足以让测试通过的代码即可。这样做将有助于使您的系统尽可能的简单。 先编写测试 XP 涉及两种测试: 程序员测试和 客户测试测试驱动的编程(也称为 测试为先编程)最常指第一种测试,至少我使用这个术语时是这样。测试驱动的编程是让 程序员测试(即单元测试 ― 重申一下,只是换用一个术语)决定您所编写的代码。这意味着您必须在编写代码之前进行测试测试指出您 需要编写的代码,从而也 决定了您要编写的代码。您只需编写足够通过测试的代码即可 ― 不用多,也不用少。XP 规则很简单:如果不进行程序员测试,则您不知道要编写什么代码,所以您不会去编写任何代码。 测试驱动开发(TDD)是极限编程的重要特点,它以不断的测试推动代码的开发,既简化了代码,又保证了软件质量。本文从开发人员使用的角度,介绍了 TDD 优势、原理、过程、原则、测试技术、Tips 等方面。 背景 一个高效的软件开发过程对软件开发人员来说是至关重要的,决定着开发是痛苦的挣扎,还是不断进步的喜悦。国人对软件蓝领的不屑,对繁琐冗长的传统开发过程的不耐,使大多数开发人员无所适从。最近兴起的一些软件开发过程相关的技术,提供一些比较高效、实用的软件过程开发方法。其比较基础、关键的一个技术就是测试驱动开发(Test-Driven Development)。虽然TDD光大于极限编程,但测试驱动开发完全可以单独应用。下面就从开发人员使用的角度进行介绍,使开发人员用最少的代价尽快理解、掌握、应用这种技术。下面分优势,原理,过程,原则,测试技术,Tips等方面进行讨论。 1. 优势 TDD的基本思路就是通过测试来推动整个开发的进行。而测试驱动开发技术并不只是单纯的测试工作
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值