httpunit 「首席架构师看敏捷数据」核心实践：测试驱动开发简介

测试驱动开发(TDD)(Beck 2003；，是一种渐进式的开发方法，结合了测试优先开发，即先编写测试，再编写足够的产品代码来完成测试和重构。TDD的主要目标是什么？一种观点认为TDD的目标是规范而不是验证(马丁、纽柯克和凯斯2003)。换句话说，这是在编写功能代码之前考虑需求或设计的一种方式(这意味着TDD是一种重要的敏捷需求和敏捷设计技术)。另一种观点认为TDD是一种编程技术。正如罗恩·杰弗里斯喜欢说的那样，TDD的目标是编写有效和干净的代码。我觉得这两个观点很有价值。虽然我比较喜欢规范的观点，但是还是留给你来决定吧。

表格内容

TDD是什么?TDD和传统测试TDD和文档测试驱动的数据库开发通过敏捷模型驱动开发(AMDD)扩展TDD为什么TDD ?神话和误解到底是谁在做这件事?总结工具1. TDD是什么?

图1中的UML活动图概述了测试优先开发(TFD)的步骤。第一步是快速添加一个测试，基本上只需要足够的代码就可以失败。接下来，运行您的测试，通常是一个完整的测试套件，尽管出于速度原因，您可能决定只运行一个子集来确保新测试失败。然后更新功能代码，通过新的测试。第四步是再次运行测试。如果它们失败了，您需要更新您的函数代码并重新测试。一旦测试通过，下一步就是重新开始(您可能首先需要重建设计中的任何重复，并根据需要将TFD转换为TDD)。

如图1所示。测试优先开发(TFD)步骤。

我喜欢用这个简单的公式来描述TDD:

TDD =重建+TFD。

TDD彻底改变了传统的发展。当您第一次实现一个新特性时，您问的第一个问题是，现有的设计是否是使您能够实现该特性的最佳设计。如果是，则用TFD法进行。如果没有，则在本地重构它，以更改受新特性影响的设计部分，这样您就可以尽可能轻松地添加该特性。所以，你总会提高自己设计的质量，从而让以后的工作更轻松。

不是先写函数代码再写测试代码，如果确实写了测试代码，应该先写测试代码再写函数代码。此外，你可以在非常小的步骤中完成——一个测试和少量相应的函数代码。使用TDD的程序员拒绝编写新的函数，直到第一次测试失败，因为函数不存在。事实上，他们甚至拒绝在测试之前添加任何代码行。一旦测试准备就绪，他们将执行确保测试套件现在通过所需的工作(您的新代码可能会破坏几个现有的测试以及新的测试)。这听起来原则上很简单，但是当你第一次学习使用TDD方法的时候，就需要严格的程序，因为不先写新的测试，很容易“溜”写功能代码。配对编程的一个优点是，配对可以帮助你保持在正确的轨道上。

通过示例指定有两个级别的TDD:

验收测试驱动开发(ATDD)。使用ATDD，您可以编写一个验收测试，或者根据您喜欢的术语编写行为规范，然后编写足够的产品功能/代码来完成该测试。ATDD的目标是在准时(JIT)的基础上为您的解决方案指定详细的、可执行的需求。ATDD也被称为行为驱动开发(BDD)。开发人员TDD。使用开发人员TDD，您可以编写单个开发人员测试，有时不准确地称为单元测试，然后编写足够的生产代码来完成该测试。开发人员TDD的目标是在JIT的基础上为您的解决方案指定一个详细的、可执行的设计。开发人员TDD通常简单地称为TDD。

图2描绘了一个UML活动图，显示了ATDD和开发人员TDD是如何结合的。理想情况下，您将编写一个验收测试，然后使用开发人员TDD方法来实现实现测试所需的生产代码。反过来，这需要您多次迭代，编写测试和产品代码，以使其在开发人员TDD级别工作。

图2。检查TDD和开发者TDD是如何协同工作的。

请注意，图2假设您同时做这两件事，尽管您可能两者都不做。事实上，一些团队将使用开发人员TDD而不使用ATDD。请参考以下调查结果，虽然如果你使用ATDD，你几乎肯定会使用开发商TDD。挑战在于，两种形式的TDD都要求从业者具备技术测试技能，但很多需求专家通常不具备这些技能(这也是泛化专家优于专家的另一个原因)。

TDD的一个基本假设是你有一个可用的测试框架。对于可接受的TDD，人们会使用Fitnesse或RSpec等工具。对于开发人员TDD来说，敏捷软件开发人员通常使用xUnit系列开源工具，比如JUnit或者VBUnit，虽然商业工具也是可行的选择。没有这些工具，TDD实际上是不可能的。图3显示了一个UML状态图，显示了人们通常如何使用这些工具。这张图表是基思·雷向我提出的。

图3。通过xUnit框架测试。

Kent Beck在极限编程(XP)中推广了TDD(Beck 2000)，他为TDD定义了两个简单的规则(Beck 2003)。首先，只有在自动测试失败的情况下，才应该编写新的业务代码。其次，您应该消除任何发现的重复。贝克解释了这两个简单的规则如何产生复杂的个人和群体行为:

您的开发是有机的，运行中的代码在决策之间提供反馈。您编写自己的测试，因为您不能每天等待20次别人为您编写测试。您的开发环境必须对小的变化提供快速的响应(e。你需要一个快速的编译器和回归测试套件)。您的设计必须由高度内聚、松散耦合的组件(例如，您的设计高度规范化)组成，以使测试更容易(这也使系统的演化和维护更容易)。

对于开发人员来说，这意味着他们需要学习如何编写有效的单元测试。贝克的经验是一个很好的单元测试:

跑得快(他们有短的设置，运行时间和故障)。单独运行(应该能够重新排序)。使用易于阅读和理解的数据。在需要时使用真实数据(例如生产数据的副本)。代表向你的总体目标迈出的一步。2. TDD和传统测试

精益敏捷atdd tdd主要是一种规范的技术，它的副作用是确保你的源代码在验证级别得到彻底的测试。然而，还有比这更多的测试。尤其是在规模方面，你还需要考虑其他敏捷测试技术，比如生产前集成测试和调查性测试。如果你选择这样做(你应该这样做)，大多数测试也可以在项目早期完成。

使用传统测试，成功的测试会发现一个或多个缺陷。TDD也是如此；当测试失败时，你取得了进步，因为你现在知道你需要解决这个问题。更重要的是，当测试不再失败时，你可以清楚地衡量成功。TDD增加了你的信心，你的系统实际上满足了为它定义的需求，你的系统实际上是工作的，所以你可以继续有信心。

与传统测试一样，系统的风险越大，测试就需要越全面。对于传统测试和TDD，你追求的不是完美，而是测试系统的重要性。套用敏捷建模(Agile Modeling，AM)的说法，你要“有目的地测试”，要知道为什么要测试，需要测试什么水平。TDD的一个有趣的副作用是你可以实现100%的覆盖率测试——每一行代码都经过测试——这是传统测试无法保证的(虽然推荐)。总的来说，我觉得可以相当肯定的说，虽然TDD是一种规范的技术，但是它有一个很有价值的副作用，就是比传统技术的代码测试结果好很多。

如果值得构建，就值得测试。如果不值得测试，为什么要浪费时间在上面呢?3.TDD和文档

不管你喜不喜欢，大部分程序员都不看系统的书面文档。相反，他们更喜欢使用代码。这个没有错。当试图理解一个类或操作时，大多数程序员首先寻找调用它的示例代码。写得好的单元测试就是这么做的——为功能代码提供工作规范——所以单元测试有效地成为技术文档的重要部分。这意味着支持文档的人的期望需要反映这个现实。同样，验收测试可以成为需求文档的一个重要部分。当你停下来思考时，这是有意义的。您的验收测试准确地定义了涉众对您的系统的期望，因此它们指定了您的关键需求。您的回归测试套件，尤其是测试优先方法，有效地变成了一个详细的可执行规范。

测试是否有足够的文档？可能不会，但它们确实是其中重要的一部分。例如，您可能会发现您仍然需要用户、系统概述、操作和支持文档。您甚至会发现您需要摘要文档来查看系统支持的业务流程。当你以开放的心态处理文档时，我怀疑你会发现这两种类型的测试覆盖了开发人员和业务涉众对文档的大部分需求。此外，它们是AM单源信息实践的一个很好的例子，也是您保持文档尽可能敏捷的整体努力的一个重要部分。

4. 测试驱动的数据库开发

在写这篇文章时，敏捷社区中提出的一个重要问题是“TDD可以用于面向数据的开发吗？”“当您查看图1中描述的过程时，应该注意到没有指定对象编程语言的步骤，例如Java或c#，即使这些是通常使用TDD的环境。为什么我不能在更改数据库模式之前编写测试？为什么我们不能根据需要改变、运行测试和重构模式？在我看来，你只需要选择这么做。

我的猜测是，在短期内，数据库TDD，或测试驱动的数据库设计(TDDD)，不会像应用程序TDD那样顺利工作。第一个挑战是工具支持。虽然现在已经有了像DBUnit这样的单元测试工具，但是在撰写本文时，它们仍然是一种新技术。一些数据库管理员正在提高他们测试的质量，但是我没有看到任何人使用TDD进行数据库开发。一个挑战是单元测试工具在数据社区中仍然没有被很好地接受，尽管这种情况正在改变，所以我的期望是数据库TDD在未来几年将会增加。其次，对于很多数据专业人士来说，进化发展的概念是新的，所以采用TDD方法的动机还没有形成。这个问题影响了数据专业人员可用工具的性质——因为串行思维在传统的数据社区中仍然占主导地位，并且大多数工具不支持渐进式开发。我希望工具供应商能跟上这种范式转变，但我的期望是我们需要开发开源工具。第三，我的经验是，大多数从事面向数据工作的人似乎更喜欢模型驱动的方法，而不是测试驱动的方法。一个原因可能是测试驱动的方法直到现在还没有得到广泛的考虑，另一个原因可能是很多数据专业人士可能是视觉思考者，所以更喜欢模型驱动的方法。

5. 通过敏捷模型驱动开发(AMDD)扩展TDD

TDD非常擅长详细的规范和验证，但是不擅长考虑更大的问题，比如整体设计，人们会如何使用系统或者UI设计(比如)。建模，或者更接近敏捷模型驱动开发(AMDD)(图4中捕获的生命周期)，更适合于此。AMDD解决了TDD没有解决的敏捷扩展问题。

图4。敏捷模型驱动开发(AMDD)生命周期。

比较TDD和AMDD:

TDD缩短了编程反馈循环，AMDD缩短了建模反馈循环。TDD提供了详细的规范(测试)，而AMDD更适合考虑更大的问题。TDD促进高质量代码的开发，而AMDD促进与涉众和其他开发人员的高质量通信。TDD提供了软件工作的具体证据，而AMDD支持您的团队(包括涉众)朝着共同的理解努力。TDD与程序员“交谈”，而AMDD与业务分析师、涉众和数据专业人员交谈。TDD提供了非常细粒度的关于分钟顺序的具体反馈，而AMDD支持关于分钟顺序的口头反馈(具体的反馈要求开发人员按照实践用代码证明它，因此依赖于非am技术)。通过关注可调用和可测试操作的创建，TDD有助于确保您的设计是干净的，而AMDD提供了在编写代码之前考虑更大的设计/体系结构问题的机会。TDD是非面向视觉的，而AMDD是面向视觉的。这两种技术对传统开发人员来说都是新技术，因此可能对他们构成威胁。这两种技术都支持进化开发。

应该采取哪种方法？答案取决于你和队友的认知偏好。有些人主要是“视觉思考者”，也称为空思考者，他们可能更喜欢通过绘画来思考。其他的主要是文本导向、非视觉或非空导向的思考者。他们不能很好地处理绘图，所以他们可能更喜欢TDD方法。当然，大多数人都处于这两个极端的中间，所以他们更喜欢在最有意义的时候使用每种技术。简而言之，答案是将这两种技术结合起来，以获得它们的优势。

这两种方法怎么结合？AMDD应该被用来和项目涉众一起创建模型来帮助研究他们的需求，然后在架构和设计模型(通常是简单的草图)中充分研究这些需求。TDD应作为建筑工程的一个关键部分，以确保开发出干净、可行的代码。最终的结果是你将拥有一个高质量的工作系统，能够满足项目涉众的实际需求。

6. 为什么TDD ?

TDD的一个显著优点是，它允许您在编写软件时采取小步骤。这是我多年来一直倡导的一种做法，因为它比试图大踏步地编写代码要高效得多。例如，假设您添加了一些新的函数代码，编译并测试它。您的测试很可能会被新代码中的缺陷损坏。如果你已经写了两行代码，那么找到并修复这些缺陷要比写两千行代码容易得多。这意味着编译器和回归测试套件运行得越快，执行越来越小的步骤就越有吸引力。在重新编译和重新运行测试之前，我通常更喜欢添加几行新的函数代码，通常少于10行。

我认为鲍伯·马丁说得很好:“编写单元测试的行为与其说是一种验证行为，不如说是一种设计行为。与其说是验证行为，不如说是文档行为。编写单元测试的行为关闭了大量的反馈回路，其中最少的一个与功能验证有关。

许多人对敏捷技术的第一反应是，他们可以接受小项目，比如几个月只涉及几个人的项目，但他们不会为更大的“真实”项目工作。这完全不是事实。Beck(2003)报道了在Smalltalk系统上使用全测试驱动的方法。用了4年40个人，生成了25万行函数代码和25万行测试代码。20分钟运行4000个测试，整个套件一天运行几次。虽然有比较大的系统，但是我在涉及几百年工作经验的系统中工作过，很明显TDD适合大系统。

7. 神话和误解

关于TDD有几个常见的误区和误区。如果可能，我想澄清一下。表1列出了这些神话，并描述了现实。

表1 .解决围绕TDD的神话和误解。

神话现实你已经创建了一个100%回归测试套件。虽然这听起来是一个很好的目标，但不幸的是，这是不现实的，原因如下:

我可能有一些可重用的组件/框架/…我下载或购买的软件没有附带测试套件，甚至可能没有源代码。虽然我可以创建黑盒测试来验证组件的接口，但这些测试不会完全验证组件。用户界面真的很难测试。尽管用户界面测试工具确实存在，但并不是每个人都拥有它们，有时它们很难使用。一个常见的策略是不自动化用户界面测试，而是希望用户测试工作涵盖系统的这个重要方面。这不是一种理想的方法，但仍然是一种常见的方法。团队中的一些开发人员可能没有足够的测试技能。数据库回归测试是一个相当新的概念，还没有得到工具的很好支持。我可能正在处理遗留系统，可能还没有抽出时间为一些遗留功能编写测试。

单元测试构成了100%的设计规格。对敏捷软件开发不熟悉的人，自称敏捷但不敏捷的人，或者可能从未参与过实际的敏捷项目的人，有时会这么说。事实上，单元测试构成了设计规范的一部分，类似的验收测试构成了需求规范的一部分，但是还有更多。如图4所示，敏捷人员实际上是建模(并记录)的，但是我们在如何做这件事上非常聪明。因为在编写产品代码之前应该考虑生产代码，所以详细的设计可以有效地执行，因为我强烈建议阅读我的单一源代码信息:有效文档的敏捷实践。你只需要做单元测试，这对于除了最简单的系统之外的所有系统都是完全错误的。敏捷社区非常清楚对大量其他测试技术的需求。TDD对于测试TDD来说已经足够了，它只是您在单元/开发人员测试和客户测试级别的整体测试工作的一部分。它最多包含您的验证测试工作，但是如图5所示，您还必须注意这个范围之外的独立测试工作。有关敏捷测试策略的更多信息，请参见敏捷测试和质量策略:事实胜于雄辩。TDD不能扩展，这在一定程度上是正确的，虽然很容易克服。TDD可扩展性问题包括:

您的测试套件运行时间太长。这是一个具有相同解决方案的常见问题。首先，将您的测试套件分成两个或更多的组件。一个测试套件包含您当前正在处理的新功能的测试，另一个测试套件包含所有测试。您将定期运行第一个测试套件，并将针对生产代码的成熟部分的旧测试迁移到整个测试套件中。整个测试套件在后台运行，通常在单独的机器上运行，并且/或者在晚上运行。在scale上，我看到了几个级别的测试套件——开发沙箱测试在5分钟或更短的时间内运行，项目集成测试在几个小时或更短的时间内运行，测试套件在很多小时甚至几天内运行，但运行的频率更低。在一个项目中，我看到了一个运行了几个月的测试套件(重点是负载/压力测试和可用性)。其次，在这个问题上投入一些硬件。并不是所有的开发人员都知道如何测试。这通常是正确的，所以让他们接受一些适当的培训，并让他们与具有单元测试技能的人合作。任何经常抱怨这个问题的人似乎都在寻找不采用TDD的借口。并非每个人都采用TDD方法。采用TDD方法进行开发是团队中的每个人都需要同意做的事情。如果有些人不这样做，那么按照优先顺序:他们需要开始，他们需要离开团队，或者您的团队应该放弃TDD。

图5。敏捷项目团队测试概述。

8. 到底是谁在做这件事?

可惜TDD的采纳率并没有我希望的那么高。图6总结了2010年的结果:你有多敏捷？提供对声称敏捷的团队正在遵循的验证策略的洞察。我怀疑开发人员TDD和接受TDD的采用率(分别为53%和44%)比2008年测试驱动开发(Test Driven Development，TDD)调查中报告的采用率实用得多。

图6。敏捷团队如何验证自己的工作。

9. 总结

测试驱动开发(TDD)是一种开发技术。在编写新的功能代码之前，您必须编写一个失败的测试。TDD正被敏捷软件开发人员迅速采用来开发应用程序源代码，甚至被敏捷dba用于数据库开发。TDD应该被视为敏捷模型驱动开发(AMDD)方法的补充，两者可以也应该一起使用。TDD并没有取代传统的测试，相反，它定义了一种行之有效的方法来确保有效的单元测试。TDD的一个副作用是生成的测试是调用代码的工作实例，从而为代码提供了一个工作规范。我的经验是TDD在实践中非常好用，所有的软件开发人员都应该考虑采用TDD。

10. 工具

以下是您可以使用的TDD工具的代表性列表。请发邮件给我提建议。我还维护了一个敏捷数据库开发工具的列表。

cpputestcsUnit (.Net)CUnitDUnit (Delphi)DBFitDBUnitDocTest (Python)GoogletestHTMLUnitHTTPUnitJMockJUnitMoqNDbUnitNUnitOUnitPHPUnitPyUnit (Python)SimpleTestTestNGTestOoB (Python)Test::Unit (Ruby)VBUnitXTUnitxUnit.net

。Net开发人员可能会发现。Net TDD工具有趣。

原文:http://agiledata.org/essays/tdd.html

这篇文章:https://pub.intelligentx.net/node/710

讨论:请加入知识星球或小红圈【总建筑师圈】