果断收藏！4个技巧成功实现测试驱动开发（TDD），使你的开发/测试资源得以最大化

本文链接：https://blog.csdn.net/Pokemogo/article/details/110922645

您如何在组织中成功推出TDD？在此文中我们将揭示：最大化采用TDD的好处的技巧，以及从纯粹到TDD-ish的TDD采用范围的探索。

测试驱动开发（TDD）的全部目的在于编写具有高水平测试覆盖率的精益代码和平均代码。开发人员在编写代码之前就编写了针对需求的测试，并且只要测试通过，就认为代码已完成。听起来不错，但是如何在组织中成功推出TDD？我们将在这里进行探讨，并为您提供一些技巧，以最大程度地采用TDD。

为什么选择TDD？

TDD的主要好处是可以帮助开发人员创建可维护和可测试的代码。TDD还通过确保创建实现功能所需的最少代码来防止代码出现特征蠕变和“镀金”现象。验证是否编写了正确的代码，还可以使团队更高效，并且避免在构建错误的功能上浪费宝贵的开发资源。

遵循TDD强制将单元测试作为组织内的一种惯例。但这不是为了单元测试而进行的单元测试。这是一种确保您正在创建可测试代码的方法，可帮助您降低维护成本并降低技术负担。通过确保您拥有可靠的回归套件，当由于代码更改而导致某些中断时，您会立即收到通知。

人们对TDD越来越感兴趣的一个主要原因是，许多组织正在过渡到敏捷开发实践，并且意识到他们现有的测试实践过于依赖周期末人工测试。端到端测试实践肯定有地方，但是为了以保持竞争所需的速度扩展开发创新，组织必须将测试工作移到左边。TDD是一个过程，几乎可以保证您以健康的测试基础启动开发项目，以确保整个开发生命周期中的软件质量。

TDD频谱

出于实际目的，出于以下几个原因，很少有软件开发人员遵循TDD的纯粹愿景。现代软件开发通常涉及集成库，连接遗留代码以及扩展现有功能。许多人没有编写全新代码的奢望，因此纯TDD在许多情况下不切实际。取而代之的是，许多“做TDD”的人坐在频谱的某个地方，看起来像这样：

尽管每个组织在TDD方面都有其自己的一系列特定挑战，但我们从客户那里听到的最多的问题都属于上述三种基本类型。但是在此范围内，TDD从业人员有很多类型：

TDD忍者

在频谱的一端，是那些“黑带”级别成功实践TDD的人。这些人完全致力于TDD原则，并且在编写测试之前不会写任何东西——没有框架，没有定义，没有任何缺点——并在测试通过后立即完成。结果，该代码是高效且高度可维护的。当我们与TDD忍者交谈时，他们常常承认，在组织内的各个团队中，实现TDD的成功并不平衡。

TDD实用主义者

下一个是可能会设计类，方法签名等，然后针对这些定义编写测试的人。在API级别，这等效于编写OpenAPI/Swagger或WSDL定义。我们称其为TDD的务实方法。

这种方法更容易采用，因为它提供了更多的结构和更高的清晰度。一切都会编译，这样一来，小队可以更轻松地一起工作。但是，潜在的权衡取舍是TDD实用主义者可能并不总是能够实现TDD忍者实现的高效、最少的代码设计。

传统的TDD

有很多人愿意完全致力于TDD，但没有从未开发代码开始的奢侈。这些人员经常创建测试以重现缺陷或测试预期的行为，以便基于遗留代码更改或扩展现有功能。

根据我们的经验，自认是从事TDD的人中有很大一部分处于或接近这一点。逻辑是，尽管测试和代码是密不可分的，但是测试不一定在代码之前。但是，在更改代码之前先进行测试。

TDD-ish

在自我识别为TDD的人员中，另一端是并行测试和编码的人员。对于TDD-ish的从业者，只要将测试和代码共同提交和管理，就可以认为开发是由测试驱动的。

实施测试驱动开发（TDD）的4条提示

那么，您如何成功采用TDD？请遵循以下四个技巧来实现TDD成功。

1.将TDD应用于旧版代码

当组织继承了无法测试的代码并且没有能力偿还技术债务时，一个常见的TDD实施问题就很棘手。代码应该重构吗？如果是这样，则需要多少重构才能开始以有意义且可实现的方式实践TDD？

如果有授权开始对遗留代码进行TDD，那么尝试实现理想的TDD将无法工作。您继承的代码并不是出于可测试性考虑而构建的，原始作者可能不再在团队中，甚至在组织中，相关库也可能已更改，依此类推。

因此，如果遗留代码已经存在并且可以正常工作，则与技术债务相关的风险要比未经测试的新工作的风险低。通过将TDD应用于您正在编写的新代码（即更改现有代码），可以将风险降到最低，并且不会增加技术负担。

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

2.将TDD应用于微服务

与传统的应用程序堆栈相比，基于微服务的体系结构具有更大的依赖性和复杂性，从而给测试环境带来了更大的波动性。由于需要高级模拟和存根，因此很难为基于微服务和其他复杂体系结构的应用程序创建测试。

但是，基于微服务的体系结构提供了以非常有效的方式利用TDD最佳实践的机会。如果您考虑将微服务视为单元而不是编译单元，那么TDD实用主义方法将非常有用。

在API级别应用TDD时，您的API在合同（OpenAPI/Swagger，WSDL）中定义。然后，API测试解决方案（例如Parasoft SOAtest）可以基于这些定义自动创建测试。现在，您可以根据定义开发功能，直到SOAtest测试通过。

3.启用小队

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

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

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

4.用BDD增强TDD

正如我们所讨论的，实现TDD有很多好处，但是TDD本身并不一定会转换为符合要求的代码。它仅确保测试覆盖代码并确保测试通过。这就是行为驱动开发（BDD）的来源。开发人员在实现行为之前一直编写代码，而不是在测试通过之前编写代码。

值得指出的是，过去曾尝试在编写代码之前定义功能框架。（有人记得合同设计（DbC）吗？）实际上，BDD是实现这种方法的最新尝试。在BDD（或DbC）中，必须在创建测试或代码之前定义前置条件和后置条件。

BDD代表了将TDD提升到新水平的机会。如果您使用的是BDD语言（例如Gherkin），则可以扩展自动化测试。Parasoft SOAtest（用于API测试）和Parasoft Selenic（用于Selenium驱动的UI测试）可以降低编写通常需要开发人员资源的必要粘合代码和步骤定义的技术复杂性。