BDD-测试驱动开发

---

当您查看有关Behave驱动开发的任何参考资料时，您会发现诸如“BDD 源自 TDD”、“BDD 和 TDD”之类的短语的用法。要知道BDD是怎么产生的，为什么说它是从TDD衍生出来的，什么是BDD、TDD，就得对TDD有一定的了解。

为什么要测试？

首先，让我们了解测试的基础知识。测试的目的是确保所构建的系统按预期工作。考虑以下示例。

因此，根据经验，我们了解到，在缺陷出现时发现缺陷并立即修复它是具有成本效益的。因此，有必要在开发和测试的每个阶段编写测试用例。这就是我们传统的测试实践所教给我们的，通常被称为“早期测试”。

这种测试方法称为“最后测试”方法，因为测试是在阶段完成后进行的。

最后测试方法面临的挑战

在软件开发项目中相当长一段时间都遵循最后测试方法。然而，实际上，使用这种方法，由于测试必须等到特定阶段完成，因此经常被忽视，因为 -

• 阶段完成的延迟。

• 时间安排紧张。

• 专注于按时交付，跳过测试。

此外，在“最后测试”方法中，通常会跳过本应由开发人员完成的单元测试。发现的各种原因基于开发人员的心态 -

• 他们是开发人员而不是测试人员。

• 测试是测试人员的责任。

• 他们的编码效率很高，而且他们的代码不会有缺陷。

这导致 -

• 损害所交付产品的质量。

• 仅由测试人员对质量负责。

• 交付后修复缺陷的成本很高。

• 无法获得客户满意度，也意味着失去回头客，从而影响信誉。

这些因素要求转变范式，将重点放在测试上。结果是测试优先的方法。

测试优先方法

测试优先方法将由内而外（编写代码然后测试）的开发方式替换为由外而内（编写测试然后编码）的开发方式。

这种方法被纳入以下软件开发方法（也是敏捷的） -

• 极限编程( XP )。_

• 测试驱动开发（TDD ）。

在这些方法中，开发人员在编写单行代码模块之前设计并编写代码模块的单元测试。然后，开发人员创建代码模块，目标是通过单元测试。因此，这些方法使用单元测试来驱动开发。

需要注意的基本点是，目标是基于测试的开发。

红-绿-重构循环

测试驱动开发用于开发由单元测试引导的代码。

步骤 1 - 考虑要编写的代码模块。

第 2 步- 编写测试

步骤 3 - 运行测试。

测试失败，因为代码还没有写。因此，步骤 2 通常称为编写失败测试。

步骤 4 - 编写尽可能最少的代码以通过测试。

步骤 5 - 运行所有测试以确保它们全部通过。单元测试是自动化的以促进此步骤。

步骤 6 - 重构。

步骤 7 - 对于下一个代码模块重复步骤 1 到步骤 6。

每个周期应该很短，典型的一个小时应该包含许多周期。

这也被普遍称为红-绿-重构循环，其中 -

• 红色- 编写失败的测试。

• 绿色- 编写代码以通过测试。

• 重构- 删除重复并将代码改进到可接受的标准。

TDD 流程步骤

TDD 过程的步骤如下所示。

TDD 的优点

测试驱动开发的好处或优点是 -

• 开发人员在创建代码之前需要首先了解所需的结果应该是什么以及如何测试它。

• 只有当测试通过并且代码被重构时，组件的代码才算完成。这确保了开发人员在进行下一个测试之前进行测试和重构。

• 由于单元测试套件在每次重构后运行，因此每个组件仍在工作的反馈是恒定的。

• 单元测试充当始终符合数据的动态文档。

• 如果发现缺陷，开发人员会创建一个测试来揭示该缺陷，然后修改代码以使测试通过并修复缺陷。这减少了调试时间。所有其他测试也会运行，当它们通过时，它确保现有功能不会被破坏

• 开发人员可以随时做出设计决策和重构，并且测试的运行确保系统仍然正常工作。这使得软件可维护。

• 开发人员有信心进行任何更改，因为如果更改影响任何现有功能，则通过运行测试会发现相同的情况，并且可以立即修复缺陷。

• 在每次连续的测试运行中，也会验证所有先前的缺陷修复，并减少相同缺陷的重复。

• 由于大部分测试是在开发过程中完成的，因此缩短了交付前的测试时间。

TDD 的缺点

起点是用户故事，描述系统的Behave。因此，开发人员经常面临以下问题 -

• 什么时候测试？

• 要测试什么？

• 如何知道是否满足规格？

• 代码能否带来商业价值？

关于 TDD 的误解

业界存在以下误解，需要澄清。

验收TDD

验收测试驱动开发 (ATDD) 在开发早期的用户故事创建过程中定义了验收标准和验收测试。ATDD注重客户、开发人员和测试人员之间的沟通和共识。

ATDD 的关键实践如下：

• 讨论现实场景以建立对该领域的共同理解。

• 使用这些场景来达到验收标准。

• 自动化验收测试。

• 将开发重点放在这些测试上。

• 使用测试作为实时规范来促进变更。

使用 ATDD 的好处如下：

• 要求明确且没有功能差距。

• 其他人理解开发人员预见的特殊情况。

• 验收测试指导开发。

TDD 与 BDD

根据 Dan North 的说法，程序员在执行测试驱动开发时通常会面临以下问题 -

• 从哪儿开始

• 测试什么和不测试什么

• 一次性测试多少

• 他们的测试该如何称呼

• 如何理解测试失败的原因

所有这些问题的解决方案是Behave驱动开发。它是从既定的敏捷实践发展而来的，旨在使敏捷软件交付新手的团队更容易访问和有效地使用它们。随着时间的推移，BDD 已经发展到涵盖更广泛的敏捷分析和自动化验收测试。

TDD 和 BDD 之间的主要区别是 -

• TDD 描述了软件的工作原理。

• 另一方面，BDD -

  • 描述最终用户如何使用该软件。

  • 促进协作和沟通。

  • 强调系统Behave的示例。

  • 针对从示例中导出的可执行规范