TDD vs BDD vs ATDD

软件开发可能是太势不可挡的。有许多语言、框架和工具需要理解。还有一些流程需要遵循。编写代码对开发人员来说通常并不困难。

 

困难在于弄清楚要写什么代码，如何处理不同的情况，并试图预测用户想要什么。我们可以通过提前编写测试来解决这个问题。这样做为开发人员提供了一组可验证的正确标准。

 

TDD(测试驱动开发)、BDD (行为驱动开发)和 ATDD (验收测试驱动开发) 都将“驱动开发” (xxDD) 作为其首字母缩写的一部分。

 

这些框架通过让我们在开发开始前做好准备来推动开发，使开发遵循预定义的路径。他们关心我们在开发之前花在计划和编写测试上的时间。测试已经就绪，为我们需要构建的内容提供了清晰的预期。我们开发人员不断地处理这些需求，当所有的测试都成功时，我们知道我们已经完成了。

 

当谈到过程选项时，每个人都有一个成功的故事来解释为什么应该使用他们的方法。我认为你应该探索不同的过程，并使用最适合你和你的团队的方法。本着这种精神，我将介绍 TDD、BDD 和 ATDD，并解释为什么您应该尝试它们。

 

TTD (测试驱动开发)

测试驱动开发定义了开发人员在编写代码之前编写测试的过程。它遵循红色>绿色>重构循环。首先，编写一个测试，看看它是否失败。这是红色的舞台。然后，编写代码使测试通过。这是绿色阶段。最后，您将检查代码和测试，并进行更改以在不破坏任何工作测试的情况下简化它们。这是重构阶段。然后重复这个循环来完成所有的需求。这通常是开发人员独有的做法，因为开发人员接受项目需求，然后编写测试和代码来实现它们。一旦所有测试通过，开发人员就可以将他们的工作交给测试人员或业务专家进行验证。

TDD测试是用代码编写的，并且应该用与系统其余部分相同的编码语言编写。开发人员已经熟悉他们的语言，所以学习编写测试应该相当容易。这些测试往往是技术性的，对于非开发人员来说很难理解。

当您有一组已知的输入和预期的输出时，TDD工作得最好。特别是当实现这些输出的逻辑很复杂时，TDD可以帮助您简化复杂性。开发人员能够将大问题分解成很小的部分，并一次专注于一件事。

 

 

 

BDD(行为驱动开发)

行为驱动开发方法有一个非常特殊的结构。业务专家在开发之前编写测试，而不是开发人员。这些测试是用一种叫做“小黄瓜”的独特句子结构写成的。当以这种方式编写测试时，软件可以将它们转换成大纲，供开发人员在其编码语言中使用。开发人员用实现测试所需的代码替换大纲。

当您拥有确切知道他们希望项目做什么的业务专家时，BDD是非常好的。他们可以通过编写表达意图的测试来驱动开发，同时为开发人员提供明确的方向。

 

给定，何时，何时

 

写出要求和给出的时间，以及句子的关键字。

 

给定用户名“user”和密码“password”，当按下登录按钮时，用户将被发送到主屏幕。

 

给定一个用户名“user”，告诉开发人员系统将需要接受用户名输入，并在这个测试中使用值“user”。然后，开发人员将使用翻译软件生成代码大纲，将重点放在单独的小代码段上。该软件自动重用编写的大纲。可以想象，随着更多测试的添加，它将变得多么强大。

 

添加一个以给定用户名“admin”开始的新测试意味着使用admin值而不作任何更改。因此，您可以看到添加新测试如何通过重用现有逻辑来加快开发速度。这意味着开发人员可以在测试的“何时”或“何时”部分关注新内容。

 

每个人都能理解这些测试的内容，因为它们的格式很容易理解。当测试失败时，您可以很容易地理解是什么导致了测试失败。由于将这些测试转换成编程语言依赖于软件，所以您需要确保您的团队可以使用BDD。

如果您不能使用BDD自动化，您仍然可以从这种方法中学习。通过遵循给定的何时编写、然后编写需求的风格，您仍然可以获得这种方法提供的一致性和易于理解。

 

 

ATDD (验收测试驱动)

验收测试驱动的开发是关于与业务专家、开发人员和测试人员协作编写测试。同样，您希望在进行编码工作之前编写测试，通过将这组人员聚集在一起，每个人在继续工作之前都能达成一致。业务专家带着他们的知识，能够在一开始就回答任何问题。开发人员了解系统当前在幕后做什么，以及在技术限制下什么是可行的。测试人员能够连接双方，同时也知道如何测试需求已经完成。通过共同定义测试和需求，团队能够灵活地适应项目的目标。

 

在此协作期间，测试人员应该实现接受开发已经完成所需的所有测试。这些测试通常比使用TDD编写的测试级别更高，但它们可能不是完整的UI自动化测试。您希望这些测试能够证明使用给定的输入集创建了预期的输出。可以将这些测试看作是一个数据输入和输出的矩阵，它可以使系统自动化。开发人员现在使用已经就位的验证测试来编写代码。了解黄瓜工具和如何使用它的BDD或ATDD，看看我们的培训课程。

 

ATDD对于在整个团队中传播知识很有价值。每个成员提供不同的专业知识，但通过这种交流，每个人都获得了更深的理解。当出现意想不到的问题时，可以发现这种方法的另一个好处。开发人员或测试人员可以使用业务专家表达的意图来回答问题，而无需等待。

 

 

TDD实施计划

通过测试来推动整个开发，但测试驱动开发不仅仅是简单的测试工作，而是一个将需求分析、设计、质量控制量化的过程。

发展原则

先写测试代码，再写函数代码。

1. 根据需求文档编写测试代码，不实现功能；
2. 不想一口就胖。测试大的功能块时，首先应该将它们拆分成更小的功能块进行测试；
3. 切记不要写代码来完成功能，用尽可能简单的代码来实现功能；
4. 如果需求可以测试，就写测试代码，不能测试的或者觉得不需要测试的就放弃；
5. 在更改/添加任何功能代码之前，首先要考虑是否要更改/添加测试用例；
6. 功能/测试代码、结构不合理、重复代码等，测试通过后及时重构。

TDD开发流程

1. 分析并确定目标测试场景；
2. 添加单元测试，验证测试场景的输入输出；
3. 运行测试，得到失败的测试结果；
4. 编写最简单的函数代码通过测试；
5. 再次运行测试，看到测试通过；
6. 进行代码重构，包括功能代码和单元测试代码；
7. 重复以上步骤，直到开发完成。

TDD 的好处

1. 减轻开发者的负担。通过一个清晰的过程，让我们一次只关注一个点，思考的负担就少了。
2. 保护网。覆盖完整的单元测试为产品代码提供了一张保护网，可以轻松应对需求变化或改进代码设计。所以如果你的项目需求稳定，一次性完成，并且没有后续变化，那么TDD的好处就少了。
3. 提前明确要求。先写测试可以帮助我们提前思考需求，明确需求的细节，而不是在代码写到一半时才发现不清楚的需求。
4. 快速反馈。很多人说TDD的时候，我的代码量增加了，所以开发效率降低了。但是，如果没有单元测试，就得手动测试，花费大量时间准备数据、启动应用程序、修改界面等等，而且反馈很慢。准确地说，快速反馈是单元测试的一个好处。

 

敏捷和 Scrum 原则

• 敏捷宣言和十二条原则
• Scrum 中最常提到的 10 条基本规则
• Scrum 团队如何运作？— 简要指南

大规模 Scrum

• 扩展敏捷框架的比较
• LeSS 框架的 10 条原则是什么？
• 如何使用 LeSS 框架管理多个 Scrum 团队？
• 前 10 名大型 Scrum 框架资源