彩票走势图

如何在你的组织中成功推广TDD？在这篇博客中：最大限度地提高采用TDD的好处的提示，以及对TDD采用的光谱的探索，从纯粹的到TDD式的。

测试驱动开发(TDD)是关于编写精简和吝啬的代码，并具有高水平的测试覆盖率。开发人员在写代码之前，先针对需求写出测试，只要测试通过，代码就被认为是完成了。听起来很不错，但是如何在你的组织中成功地推出TDD呢？我们将在这里探讨这个问题，其中会有一些提示，让你最大限度地发挥采用TDD的好处。

为什么选择TDD？

TDD的主要好处是帮助开发人员创建可维护和可测试的代码。TDD还可以通过确保创建实现功能所需的最低限度的代码来防止功能爬升和代码的 "镀金"。验证正在编写的代码是否正确，也使团队更加高效，避免将宝贵的开发资源浪费在构建错误的功能上。

遵循TDD在组织内部强制执行单元测试作为一种实践。但这不是为了单元测试而单元测试。它是一种确保你正在创建可测试代码的方法，帮助你降低维护成本并保持技术债务的低水平。通过确保你有一个坚实的回归套件，当一些东西因代码更改而中断时，你会立即得到通知。

对TDD的兴趣越来越大的一个重要原因是，许多组织正在向敏捷开发实践过渡，并意识到他们现有的测试实践过于依赖周期末的手动测试。端到端测试实践当然有一席之地，但为了以保持竞争力所需的速度扩展开发创新，组织必须将测试工作左移。TDD是一个过程，它完全可以保证你在开发项目开始时有一个健康的测试基础，以确保整个开发生命周期的软件质量。

TDD频谱

就实际目的而言，很少有人开发软件时遵循TDD的纯粹愿景，原因有几个。现代软件开发通常涉及整合库、连接遗留代码和扩展现有功能。很多人并不奢望编写全新的代码，所以纯TDD在很多情况下并不实用。相反，许多 "做TDD "的人坐在类似这样的光谱上。

虽然每个组织在TDD方面都有自己的一套具体挑战，但从客户那里听到最多的问题符合上述三种基本类型。但在这个范围内，TDD从业者有很多类型。

TDD Ninjas

在光谱的一端，是那些成功实践TDD的 "黑带 "级别的人。这些人完全致力于TDD原则，在写测试之前不写任何东西--没有骨架，没有定义，没有任何东西--只要测试通过就结束了。因此，代码效率高，可维护性强。当人们与TDD Ninjas交谈时，他们经常承认，他们在组织内部各团队实施TDD的成功率是不均衡的。

TDD实用主义者

接下来的人可能会设计类、方法签名等，然后针对这些定义编写测试。在API层面，这相当于编写OpenAPI/Swagger或WSDL定义。我们称之为TDD的实用主义方法。

这种方法更容易采用，因为它提供了更多的结构和更清晰的内容。所有的东西都是编译的，这样一个小队就可以更容易地一起工作。然而，潜在的权衡是，TDD实用主义者可能并不总是能实现TDD忍者所实现的高效率、最小化的代码设计。

传统的TDD

有很多人很想完全投入到TDD中去，但又不舍得从绿地代码开始。这些人经常创建测试来重现缺陷，或者测试预期的行为，以便基于遗留代码改变或扩展现有功能。

在那些自认为是TDD实践者的人中，有很大一部分人处于或接近这个谱系中的这一点。其逻辑是，虽然测试和代码是密不可分的，但测试并不一定先于代码。然而，测试确实先于代码的修改。

TDD式

TDD的另一端，是测试和代码并行的人。对于TDD式的从业者来说，只要测试和代码一起投入和管理，就认为开发是由测试驱动的。

实施测试驱动开发（TDD）的4个技巧

那么如何成功采用TDD呢？按照下面的四个技巧来实现TDD的成功。

• 将TDD应用于遗留代码

当一个组织继承了不可测试的代码，而它又没有能力偿还技术债务时，一个常见的TDD实现问题再次出现。是否应该对代码进行重构？如果是的话，需要多少重构才能以有意义的、可实现的方式开始实践TDD？

如果有任务开始在遗留代码上做TDD，那么试图实现理想的TDD是行不通的。你所继承的代码并没有考虑到可测试性，原作者可能已经不在团队甚至不在组织中，依赖的库可能已经发生了变化，等等。

所以，如果遗留代码已经在那里工作了，相对于新的未经测试的工作的风险，技术债务带来的风险是很低的。通过将TDD应用于你正在编写的新代码，即对现有代码的修改，你可以将风险降到最低，并且不会增加技术债务。

为了克服测试现有代码的挑战，您可以使用Parasoft Jtest的单元测试功能来快速创建有意义的测试。Parasoft Jtest可以分析遗留代码及其依赖关系，减少创建JUnit测试用例和实现现有代码所需的复杂存根/对接的时间。

• 将TDD应用于微服务

基于微服务的架构比传统的应用堆栈具有更多的依赖性和复杂性，将更多的不稳定性引入到测试环境中。由于需要先进的嘲讽和存根，为基于微服务和其他复杂架构的应用程序创建测试可能是困难的。

然而，基于微服务的架构提供了以非常有效的方式利用TDD最佳实践的机会。如果你把微服务视为单元，而不是编译单元，那么TDD实用主义方法就会变得非常有用。

当在API层面应用TDD时，你的API是在合同（OpenAPI/Swagger，WSDL）中定义的。API测试解决方案，如Parasoft SOAtest，就可以根据这些定义自动创建测试。然后只需要准备好根据定义开发功能，直到SOAtest测试通过。

• 启用小队

TDD通常被视为以开发人员为中心的活动，通常通过在单元测试框架（如JUnit或NUnit）中创建测试来封装。然而，大多数组织根本没有足够的开发人员或时间来覆盖所有的用例。这对于那些对其项目有多种角色和技能贡献的企业组织来说，尤其是一个问题。

如上文所述，在API层面利用TDD实践来处理微服务，可以帮助您解决技术资源有限的问题，使您能够利用测试人员的专业知识来根据合同定义测试。通过这种方法，业务分析师、测试人员和其他非开发人员资源能够为TDD测试工作做出贡献。

您也可以使用服务虚拟化解决方案，如Parasoft Virtualize，来立即创建模拟功能，您可以在编写任何代码之前，针对这些功能构建和执行测试。

• 用 "局域分工 "加强时效性

实现TDD有几个好处，但TDD本身并不一定能转化为符合需求的代码。它只是确保代码被测试所覆盖，并且测试通过。这就是行为驱动开发（BDD）的作用。开发者不是在测试通过之前写代码，而是在行为实现之前写代码。

值得指出的是，过去曾有人试图在编写代码之前定义功能框架。有谁还记得按合同设计（DbC）吗？事实上，BDD是实现这种方法的最新尝试。在BDD（或DbC）中，在创建测试或代码之前，必须先定义前和后条件。BDD代表着将TDD提升到一个新的水平的机会。如果你使用的是BDD语言，如Gherkin，你可以扩展自动化测试。而Parasoft SOAtest(用于API测试)和Parasoft Selenic(用于Selenium驱动的UI测试)可以降低编写必要的胶合代码和步骤定义的技术复杂性，而这通常需要开发人员资源。

结论

测试驱动开发的承诺是基于精益开发理念的。它旨在帮助你生成高效、可测试、可维护的代码。但现实世界的条件并不总是让TDD的采用变得容易。 可以帮助您以一种对您的组织来说实用的方式采用 TDD 实践，使您能够最大限度地利用您的开发/测试资源。联系在线客服，了解如何帮助您在组织中实施TDD的详情。