敏捷联盟Gordon Pask奖获得者讲“测试驱动开发”TDD

测试驱动的面向对象软件开发(预订中,估价)

《测试驱动的面向对象软件开发》 前言

原书名:Growing Object-Oriented Software,Guided by Tests

作者:Steve Freeman Nat Pryce(敏捷联盟Gordon Pask奖获得者,Mock技术早期创始人)


这本书是讲什么的

这是一本实践指南,介绍了我们发现的编写面向对象软件的最好方式:测试驱动开发(test driven development,TDD) 。它描述了我们遵循的过程、追求的设计原则,以及使用的工具。它以我们数十年的经验为基础。在这些年里,我们与世界上一些最好的程序员共事,向他们学习。

本书讨论了一些问题与困惑,它们是我们在一个个项目中所见到的。如何将测试驱动开发应用到软件项目中?我从哪里开始?为什么我应该既编写单元测试,又编写用户场景测试?测试“驱动”开发是什么意思?如何测试某个难弄的特征?

本书同时也着重讨论了设计,以及设计方式对TDD方式所产生的影响。如果说我们从中学到了什么,那就是测试驱动开发作为一个整体时,效果最好。我们曾看到过一些团队虽然采用了一些基本实践(编写并运行测试),但他们仍不得要领,因为他们并没有采用背后更深层次的过程。

为什么“培育”面向对象软件

本书使用“培育”(Growing)这个词是因为它让人们感觉到开发是增量式的。我们在任何时候都有可以工作的软件,确保代码总是尽可能地具备良好的结构,并经过全面的测试。任何事情都不比交付可以工作的系统更有效。正如John Gall在[Gall03]中所写的,“能工作的复杂系统总是从能工作的简单系统演进而来的。”

“培育”也暗示了一个在好的软件中发现的生物学特点,即在每一层结构中一致的感觉。它将我们的方式与面向对象结合起来,正好与Alan Kay的观点一致,即对象像生物细胞一样彼此发送消息。

为什么要以测试为“指导”

我们先写测试,因为我们发现这有助于写出更好的代码。先写一个测试迫使我们澄清自己的意图,只有无二义地描述了应该做什么以后,我们才会开始下一步的工作。先写测试的过程帮助我们发现设计是否太僵硬或没有关注要点。然后,当我们希望继续下一步工作并修复设计缺陷时,测试可以提供回归覆盖测试构成的安全网。

本书使用“指导”(Guided)这个词,是因为此项技巧仍然需要使用者的技能和经验。我们发现测试驱动开发是一种有效的设计支持工具——只要我们学会如何增量式地开发并“聆听测试”。像其他正规的设计活动一样,TDD需要理解和持续的努力才有效。

我们曾发现一些团队同时编写测试和代码(甚至有一些团队先写测试),他们的代码仍然一团糟,测试只是增加了维护的成本。他们已经起步,但还没有明白这种技巧是要让测试来指导开发。利用测试的内容,将关注点放在取得进展上,并利用测试的反馈来提升系统的品质。

什么是模拟对象

编写本书最初的动机是完整解释使用模拟对象(Mock Object)的技术,我们看到这种技术常被人误解。随着写作的深入才意识到,我们社区对模拟对象的发现和使用实际上体现了我们写软件的方式。这是大局观的一部分。
本书将利用jMock库来展示模拟对象是如何工作的。更具体地说,我们将展示模拟对象应该用于TDD过程的什么位置,以及它在面向对象开发的环境中具有怎样的意义。

这本书为谁而写

这本书是为“有一定知识的读者”而写的。它的目标读者是具有专业经验的开发者,他们至少曾看过测试驱动开发。 在编写时,我们假设是向一些以前未接触过这些技术的同事进行解释。

为了留出篇幅以介绍更深入的内容,我们假定读者具备有关基本概念和工具的一些知识。别的一些书对TDD进行了很好的介绍。

这是一本Java书吗

本书从头到尾使用Java语言,因为它非常普及,我们希望读者至少能理解这些例子。也就是说,本书实际上是在介绍任何面向对象环境都适用的一组技巧。

如果您目前不用Java,在许多其他语言中也有与我们使用的测试和模拟库(JUnit和jMock)等价的类库。这些语言包括C#、Ruby、Python、Smalltalk、Objective-C,以及(令人印象深刻的) C++。甚至还有更少见的语言的版本,如Scala。在Java中,也有其他的测试框架和模拟框架。

为什么您要听信我们

《测试驱动的面向对象软件开发》 汇集了我们几十年的经验,包括近十年的测试驱动开发。在这段时间里,我们在各种项目中使用TDD。这些项目包括:面向消息的大型企业集成系统(具有交互式Web前端和多处理器计算网格后端)、微型嵌入式系统(必须运行在几十KB的内存中)、用作关键业务系统广告的免费游戏、后端中间件和网络服务(支持高度交互的图形桌面应用)。而且,我们为世界各地的会议和公司讲授这些内容。

我们也从同事的经验中获益,他们来自伦敦的TDD社区。我们花了不少工作时间和业余时间让思想接受挑战和磨炼。我们很感谢能有机会与这样活跃的(善于争论的)同事一起工作。

本书有些什么内容

这本书有五个部分:

第一部分“简介”,是在软件开发项目背景下,对测试驱动开发、模拟对象和面向对象设计的高层次的介绍。同时也介绍了本书其他部分中用到的一些测试框架。即使您已经熟悉TDD,仍然建议您通读第1章和第2章,因为它们描述我们进行软件开发的方法。如果您熟悉JUnit和jMock,您也许愿意跳过简介的其他部分。

第二部分“测试驱动开发过程”,描述了TDD过程,展示了如何开始开发,并让开发进行下去。我们深入探讨了测试驱动开发和面向对象编程之间的关系,说明了这两种技术的原理是如何相互支持的。最后,我们讨论了如何处理外部代码。这一部分介绍了概念,下一部分将这些概念投入实战。

第三部分“工作的例子”,是一个扩展的例子,让您初步体验一下以测试驱动的方式来开发面向对象应用。在整个过程中,我们讨论了一些折中和做决定的动机。这个例子相当长,因为我们希望说明TDD的某些特征是怎样随着代码规模的扩大变得更为重要的。

第四部分“可持续的测试驱动开发”,描述了一些保持系统可维护的实践。我们现在非常注意保持代码整洁和富有表现力,因为这些年来,我们已经了解了代码变差的代价。这部分描述我们采用的一些实践,并解释了为什么这么做。

第五部分“高级主题”,探讨了TDD更难的一些方面:复杂的测试数据、持久性和并发性。我们展示了处理这些问题的方法,并讨论了这对代码的设计和测试所产生的影响。

最后,附录包含了关于jMock和Hamcrest的一些支持材料。

本书不包含什么内容

这是一本技术书籍。我们不讨论使项目成功的其他主题,如团队组织、需求管理和产品设计。采用增量式的、测试驱动的方法来开发显然与项目运作的方式有着密切的关系。TDD支持一些新的活动,例如频繁交付;它也会被一些组织环境破坏,例如早期设计冻结或利益相关人之间缺乏沟通。同样,有许多其他书籍讨论这些主题。

作者简介

Steve Freeman是一名独立咨询师,擅长领域是敏捷软件开发(http://www.m3p.co.uk)。他与Nat Pryce一同赢得了2006年敏捷联盟的Gordon Pask奖。他是伦敦极限星期二俱乐部(London Extreme Tuesday Club)的创建成员,也是第一任伦敦XP日(London XP Day)的主席,还经常在国际会议上担任组织者和演讲者。Steve曾在各种类型的组织中工作过,从为IBM开发完整零售版软件,到为大的研究实验室开发原型。Steve拥有剑桥大学的哲学博士学位,并拥有统计和音乐学位。Steve居住在英国伦敦。

Nat Pryce在帝国理工学院取得博士学位之后,Nat Pryce加入了.com风潮,刚好看到泡沫破灭。从那时起,他就在许多不同的行业(包括体育新闻报道、市场营销传播、零售、电信和金融业)中当程序员、架构师、培训师和咨询师。他也曾参加学术研究项目,偶尔在大学任教。作为XP的早期采用者,他编写了一些支持TDD的开放源码库,对一些库作出了贡献,他也是伦敦XP日(London XP Day)的发起组织者之一。他也经常在国际会议上发表演讲。Nat居住在英国伦敦。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结