演化架构与紧急设计: 测试驱动设计,第1部分

常见的一种敏捷开发实践就是 TDD。TDD 是一种编写软件的模式,它使用测试 帮助您了解需求阶段的最后步骤。先写测试,再编写代码,这样可以巩固您对代 码所需执行的操作的理解。

大多数开发人员认为 TDD 带来的主要好处是最终得到的综合单元测试集。但 是,如果正确执行的话,TDD 可以改进代码的整体设计,因为它将决策推迟到最 后责任时刻(last responsible moment)。由于您没有预先做出任何设计决定, 因此它让您随时可以采用更好的设计选择或者重构为更好的设计。本文将介绍一 个示例,用于演示根据单元测试的结果进行设计的强大之处。

TDD 工作流程

测试驱动开发 术语中的关键词是驱动,表示测试将驱动开发流程。图 1 显示 了 TDD 工作流程:

图 1. TDD 工作流程

图 1 中的工作流程是:

编写一个失败的测试。

编写代码以使测试通过。

重复第 1 步和第 2 步。

在此过程中积极地重构。

当您无法再想到任何测试时,那么就必须做决策了。

时间: 2024-10-22 02:31:41

演化架构与紧急设计: 测试驱动设计,第1部分的相关文章

演化架构与紧急设计: 测试驱动设计,第2部分

本文是分两部分的文章的第二部分,讨论如何使用 TDD 在编写代码之前编写 测试,并通过这个过程形成更好的设计.在 第 1 部分 中,我采用后测试开发方 法(在编写代码之后编写测试)编写了完全数查找程序的一个版本.然后,使用 TDD(在编写代码之前编写测试,这样就可以用测试驱动代码的设计)编写了另一 个版本.在第 1 部分的末尾,我发现我在用来保存完全数列表的数据结构类型方 面犯了一个根本性错误:我最初根据直觉选用了 ArrayList,但是后来发现 Set 更合适.我将以这个问题为起点,讨论如何

演化架构与紧急设计: 通过指标进行紧急设计

简介: 软件指标可以帮助您寻找代码中隐藏的设计元素,让它们能够成为惯用模式. 演化架构与紧急设计 的这一期讲解如何使用指标和可视化发现被复杂性掩盖的重要代码元素. 紧急设计的难题之一是寻找隐藏在代码中的惯用模式和其他设计元素.指标和可视化有助于识别代码的重要部分,从而提取出一些设计元素.本文主要讨论两个指标,圈复杂度(cyclomatic complexity) 和传入耦合(afferent coupling).圈复杂度度量方法的相对复杂度.传入耦合表示有多少个其他类使用当前类.本文要介绍显示和

演化架构与紧急设计:对设计进行重构

在 "测试驱动设计,第 1 部分" 和 "测试驱动设计,第 2 部分" 中,我 介绍了测试如何为新的项目实现更好的设计.在 "组合方法和 SLAP" 中,我讨 论了两种关键模式 - 组合方法(composed method)和单一抽象层原理 - 为您 的代码结构提供了整体目标.需要牢记这些模式.一旦拥有了一个现有软件项目 ,那么发现和利用设计元素的主要方法就是进行重构.在 Martin Fowler 的经典 著作 Refactoring 中,他将

演化架构和紧急设计:利用可重用代码,第1部分

简介:识别出代码中的惯用模式后,下一步是积累和使用它们.理解设计与代码之间的关系有利于发 现可重用的代码.本期的 演化架构与紧急设计 探索代码与设计的关系,使用表达性强的语言的重要性, 以及重新考虑抽象风格的潜在价值. 通过本 系列 的前几期,您已经知道,我的观点是软件的每个部分都包括可重用的代码块.例如,公 司处理安全性的方式在整个应用程序甚至多个应用程序中可能都是一致的.这就是我所说的 惯用模式 的 实例.这些模式代表对构建软件特定部分时遇到的问题的常用解决方案.惯用模式有两种类型: 技术模

演化架构和紧急设计: 利用可重用代码,第2部分

简介:在使用 演化架构和紧急设计 前几期描述的技术发现 代码中的紧急设计之后,下一步您需要一 种获取和利用这些设计元素的方法.本文介绍了两种用于获取惯用模式的方法:将模式作为 APIs 进行捕 捉:使用元程序设计方法. 本 系列 的前几期主要关注紧急设计中显而易见的第一步:发现 惯用模式.发现惯用模式之后,您要 用它做什么?该问题的答案就是本期重点,本文属于由多个部分组成的系列文章的第二部分.第 1 部分 -代码与设计的关系探讨- 介绍了一种观点的理论基础,这种观点就是软件中的设计真正是指解决方

演化架构和紧急设计: 演化架构

简介: 这一期的 演化架构和紧急设计 将会解决演化架构相关的各种主题,包括设计和架构之间的重 要区别(以及如何区分两者),您在创建企业级架构时遇到的某些问题,以及面向服务的架构中静态类型 和动态类型的区别. 在 本系列的第一期 中,我推荐了软件世界中的一些架构定义.无论如何,如果您已经阅读过本系列 ,您会注意到我花费了大部分时间在设计上.我之所以这么做是基于以下几个原因:首先,在当前紧急设 计尚未被广泛关注时,软件世界里存在很多架构定义(良莠不齐):其次,在设计方面很多问题都有具体 的.不受环境

演化架构与紧急设计: 积累惯用模式

简介: 本期将之前的 演化架构与紧急设计 文章中的紧急设计概念与一个案例研究相结合,展示如何 发现.积累和利用代码中意料之外的设计元素.一旦理解了如何识别设计元素,便可以使用该知识改进代 码的设计.紧急设计使您可以发现代码中意料之外但是已成为代码库重要部分的那些方面. 在本系列第一期 "研究架构和设计" 中,我曾断言每个较大的项目都包括超出所有人意料的设计元 素.详细考虑一个问题时,常常会发现有些本以为困难的事情实际上却更容易,有些本以为容易的事情实 际上却更困难.随后的几期则演示了发

演化架构与紧急设计: 组合方法和 SLAP

简介:如何在陈旧的代码库中找出隐藏的设计?本文讨论两种对于代码结构很重要的模式:组合方法 和单一抽象层.对代码应用这些原则有助于找到以前隐藏的可重用资产,有助于把现有的代码抽象为成熟的框架. 在这个 系列 的前两期中,我讨论了如何使用测试驱动开发 (TDD) 帮助您逐步发现设计.如果从头开始一个新项目,这种方法的效果非常 好.但是,更常见的情况是您手中已经有许多并不完善的代码,在这种情况下应该怎么办呢?如何在陈旧的代码库中找出可重用的资产和隐藏 的设计? 本文讨论两个很成熟的模式,它们可以帮助您

演化架构与紧急设计:研究架构和设计

演化架构(evolutionary architecture)和紧急设计(emergent design)都是将 重要的决策推迟到最后责任时刻(Last Responsible Moment)的敏捷技术.在本 系列的第一期文章中,系列作者 Neal Ford 将定义架构和设计,然后指明了一些 关于整个系列的基本概念. 软件架构和设计一直都没有一个明确的定义,因为软件开发作为一门学科,尚 未完全理解其中的复杂度和内涵.但是要发表关于这些主题的论述,您必须从某 个位置开始.本系列涉及演化架构和紧急设