Test Driven Development (TDD)介绍
|
[ 原文 : Introduction to Test Driven Development (TDD)] [ 中文名 : 测试驱动开发介绍 (TDD)] [ 出处 : http://www.agiledata.org/essays/tdd.html ] [ 作者 : Scott W. Ambler ] [ 翻译 :极地银狐 .NET ] ? 测试驱动开发是一种先开发测试的先进技术，即你在编写足够的产品代码用于测试和重构之前就编写测试。测试驱动开发的初衷是什么呢？一种观点是 TDD 是一种规范而不是校验。就是说它是在你编码之前就惯穿设计的一种思考。另一个观点是 TDD 是一种编码技术，就像 Ron Jeffries 喜欢说的那样 TDD 可用来编写干净的可工作的代码。尽管我把决定权留给读者，但我想以上两点各有其道理。 ? 目录 一、 ?????? 什么是 TDD？ 二、 ?????? TDD与传统测试 三、 ?????? TDD与文档 四、 ?????? 测试驱动数据库开发 五、 ?????? TDD与敏捷模型驱动开发（ AMDD） 六、 ?????? 为什么使用 TDD？ 七、 ?????? 小结 八、 ?????? 工具 ? 一、??????????? 什么是 TDD ？先行测试开发 (Test First Development - TFD) 的步骤已在图一的 UML 活 动图中概括出来了。首先快速加入测试以及足以使测试失败的代码。然后运行测试，当然可能由于速度的原因你只决定运行整个测试的一小部分，用于确认新测试的 失败。你修改你的功能代码使此次测试通过。第四步是再测试此代码，如果还是失败那你可能还要继续修改你的代码直到通过测试为止。一旦通过试就再回到第一步 重新做起（可能你首先要重构设计中任何重复的代码，从 TFD 转到 TDD ）。 图一：先行测试开发步骤
我喜欢用以下简单的公式描述 TDD ： TDD=TFD+ 重构 TDD 和传统的测试是完全的两回事。你使用写功能代码之前编写测试代码这种方式来替代先写功能代码再追加测试代码。更多的，你以很小的步骤来做此事 — 一次只写一个测试代码和相应的功能代码。一个遵循 TDD 开 发步骤的程序员会因为不是当前的功能代码而拒绝写新的直到有一个会失败的测试代码。实际上就算是多一行代码他们都是不愿意的，除非有新的测试。一旦有了测 试代码他们才会做相应的开发来确认测试的通过（你的新功能和测试代码可能会扰乱现有的测试）。只要你的代码通过测试了，那就要重构它以确保代码质量。这在 原则上听起来简单，但当你第一次用 TDD 开发步骤时它会证明（你）需要更多的训练，因为它很容易出现“脱节”而引起编写功能代码之前没有编写测试代码。结对编程（ Williams and Kessler 2002 ）的一个优点就是你的搭档会帮助你跟踪。 ? TDD 一个潜在的假设是你有一个可用的单元测试框架。尽管商业工具是一个可选的方案，但大多数敏捷开发人员还是愿意使用 xUnit 系列的开源工具，比如 JUnit 或 VBUnit 。没有这些工具 TDD 实际上是不可能的。图 2 是一个 UML 状态图，描述了人们是如何在典型的开发中使用 xUnit 工具的。这个图是 Keith Ray. 推荐给我的。 图 2 ：通过 xUnit 框架进行测试
Kent Beck ，一位致力于在极限编程（ XP ， Beck 2000 ）中普及 TDD 的人，他为 TDD 定义了两条简单的规则（ Beck 2003 ）。一，在自动测试失败时只编写业务代码；二，消除任何你找到的任何重复（的代码或设计）。 Beck 解释了这两条规则是如何展现复杂的个体以及如何组织行为：
? 二、??????????? TDD 与传统测试TDD 原本是一种编程技术，它间接地确保你的代码能彻底地被单元测试检查。可是，它能做的不只这些。你仍然需要参考传统的一些测试比如功能测试、用户验收测试、系统集成测试等等。大部分的这些测试都可以在项目开始之前就进行，如果你选择这么做的话（而且你也应该这么做）。实际在 XP 里，项目负责人指定的用户验收测试在编码时或是更早就开始进行了。告诉项目负责人系统能适应需求，增强他的信心！ ? 一个好的传统测试能发现一个或多个漏洞，此理论同样适用于 TDD 。当一个测试失败的时候你必须进行改进因为你知道你需要解决这个问题。更重要的是，当你的测试不再失败的时候你就可以清楚地知道成功了多少。 TDD 增强了你的信心因为它适应了预先定下的需求，你的系统能正常运行了，因此你再自信地开发下去。 ? 像传统的测试一样，项目风险越大，就要更彻底地进行测试。传统测试和 TDD 中你都不可能为着完美而奋斗，代之的是测试系统的重要性。为了解释敏捷模型（ Agile Modeling ， AM ），你应该“带着目的去测试”、知道为什么要测试以及测试是在什么等级。 TDD 为你带来的有趣的间接影响是，你的代码测试覆盖率是 100%— 每一行都被测试过了 — 这是传统测试所不能保证的（虽然它们推荐这么做）。一般来讲我会很负责任地说 TDD 的结果比传统技术更有意义。
三、??????????? TDD 与文档大部分的程序员都不喜欢读现有系统的文档，他们更喜欢看代码。这也无可厚非。当要了解一个类或是操作的时候他们一般是先去找相关的示例代码调用。书写良好的单元测试正是这么做的 — 它为你的功能代码提供了工作指引 — 作为结果的，单元测试有效地成为你技术文档有意义的一部分。这暗示着预期要用到的文档必须实事求是。 ?????? 四、?????????? 测试驱动数据库开发直到写这篇文章的时候，在敏捷开发团队中仍然在讨论一个问题：“ TDD 是否能用于面向数据的开发？”正如你在图 1 中所看到的处理流程那样，没有一个步骤是用某种特定的语言来描述的，比如 JAVA 或是 C# ，即使它们是 TDD 的典型使用环境。为什么不能在你修改数据库结构之前写一个测试？为什么你不做一些改变，运行测试，然后根据要求重构你的（数据库）结构？在我看来你只需要选择这样的工作方式就行。 ? 我猜测在短期内数据库 TDD 没有一般应用程序的 TDD 好使。第一个挑战就是工具的支持。虽然单元测试工具，比如 DBUnit ，在写此文的时候现在已经表现出其可用的一面了。一些 DBA 正在提升他们测试的质量，但我没有看到哪个 TDD 接近了数据库开发的目标。另一个挑战是单元测试工具在数据库团队中并不能被很好的接受，虽然这正在被改变。所以我希望的是在以后的几年里数据库 TDD 成长起来。第二，新的开发概念对于很多数据库专家来说是比较新的，其次作为结果，使用 TDD 方式的动机一直悬而未决。这种情况会影响了数据库专家的工具的可用性 — 由 于传统的思维在数据库团队里起支配作用而使得大多数工具不支持先进的开发方式。我希望工具提供者能和范例同步，但我希望的是我们用开源工具来代替。第三， 我希望的是大多数在面向数据工作不喜欢测试驱动开发只喜欢模型驱动开发的人，我之所以这么说是因为直到目前测试驱动开发还没有被大范围的考虑。另一个理由 是目前很多数据库专家都是喜欢虚拟设计，喜欢模型驱动开发。 五、??????????? TDD 与敏捷模型驱动开发（ AMDD ）将 TDD 与模型驱动开发（ MDD ）相比较如何？或者是说和敏捷模型驱动开发（ AMDD ）呢？我相信：
? 你会采用哪种？答案取决于你，你的同伴，你自己的偏爱。一些人是“可视化思考者”，或是叫空间思考者，他们喜欢通过画东西来思考。另一些人偏向于组织文字，非可视化者或是非空间思考者，他们工作中不擅长画图，喜欢用 TDD 的方式。当然更多的人是在这两种极端之前，凭借感觉来适当地使用两种技术。简而言之，两种技术都使用以获取两种技术中的优点。 如何结合这两种技术？ AMDD 应用在和你的项目负责人一起建模以帮助浏览需求以及需求在架构和设计中的充分体现（通常是简单的草图）。 TDD 是用于确保你开发代码的整洁、可靠的重要组成部分。最后的结果是你有一个高质量、符合项目负责人要求的工作系统。 六、??????????? 为什么使用 TDD ？TDD 的一个好处是能让你小步小步地写软件。这是我几年来一直推行的方法因为它要比大步完成更具生产力。假设你有一些新的功能代码，编译和测试它们。当测试失败的时候你有很好的机会来排错。你能很快发现错误并修复它，这些错误可能是需要写两行代码，远远好过于你写 2000 行代码。同时也意味着你的编译和回归测试加快了。可见小步处理更具魅力。一般来说我喜欢在重新编译和测试之前加入新的几行代码，一般来说是 10 行以下。 ? 我想 Bob Martin 说的对，“编写单元测试更像一种设计行为，文档行为而不是验证行为。编写单元测试缩短了反馈周期读数，最小读数基于功能验证。”（ Martin,Newkirk,and Koss 2003 ） ? 敏捷技术给大多数人带来的第一误会是只适用于小项目，也许就是几个人花几个月时间的那种，不是那种“真正”的大项目。这明显错了。 Beck (2003) 报道了在 Smalltalk 下一个完全测试驱动开发的项目， 40 人年，有 250000 行功能代码和 250000 行测试代码。在 20 分钟里要跑 4000 个测试，一天中要进行好几次完全的测试。虽然算是大项目了，但我以前参加过更大的，几百人年的工作量（用 TDD 完成），由此可见 TDD 适用于任何大小的系统。 七、??????????? 小结测试驱动开发（ TDD ）是一种在添加新代码之前让你的测试代码出错的一种开发技术。 TDD 很快被敏捷开发人员采用来进行应用系统源代码开发，很快也会将被敏捷 DBA 用于数据库开发。 TDD 可以作为敏捷模型驱动开发的补充方法（ AMDD ）而且两者可以一起使用。 TDD 不能替代传统的测试，相反它定义一种验证方式来确保单元测试的有效性。 TDD 的另一个作用是测试代码可以作为代码示例，因此可以为我们提供编码规范。在我的经验看来， TDD 在实际开发中表现的难以相信的出色以至于很多敏捷开发者考虑采用之。 八、??????????? 工具以下是一些典型的可用的 TDD 工具，如果有建议请 给我写信 。
（编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
