📜  BDD-测试驱动开发

📅  最后修改于: 2021-01-18 05:33:17             🧑  作者: Mango


当您查看有关行为驱动开发的任何参考时,您会发现诸如“ BDD源自TDD”,“ BDD和TDD”之类的短语的用法。要了解BDD是如何形成的,为什么据说它是从TDD派生的以及什么是BDD和TDD,您必须对TDD有一定的了解。

为什么要测试?

首先,让我们进入测试的基础。测试的目的是确保构建的系统按预期工作。考虑以下示例。

测试中

因此,根据经验,我们发现,发现缺陷并在引入缺陷时立即加以修复将具有成本效益。因此,有必要在开发和测试的每个阶段编写测试用例。这就是我们传统的测试实践向我们传授的知识,通常被称为“早期测试”。

探索性测试

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

最后测试方法的挑战

在软件开发项目中,采用了“最后测试”方法已经有一段时间了。但是,实际上,使用这种方法时,由于测试必须等到特定阶段完成,因此通常会被忽略,因为-

  • 延迟完成阶段。

  • 时间表紧张。

  • 专注于准时交货,跳过测试。

此外,在“最后测试”方法中,通常会跳过应该由开发人员完成的单元测试。找到的各种原因都是基于开发人员的思维方式-

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

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

  • 它们的编码效率很高,并且其代码不会有缺陷。

这导致-

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

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

  • 修复缺陷,后期交货的高成本。

  • 无法获得客户满意度,这也将意味着重复业务的损失,从而影响信誉。

这些因素要求改变范式,将重点放在测试上。结果就是“测试优先”的方法。

测试优先方法

“测试优先”方法将开发过程由内而外(先编写代码,然后进行测试)替换为由外而内(先编写代码,然后进行代码)开发。

此方法已合并到以下软件开发方法中(它们也是敏捷的)-

  • E X德特雷姆PAGC(XP)。

  • ŤEST d里文d才有发展(TDD)。

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

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

红绿重构循环

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

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

步骤2-编写测试

步骤3-运行测试。

测试失败,因为仍未编写代码。因此,通常将步骤2称为编写失败测试。

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

步骤5-运行所有测试以确保它们仍然通过。单元测试是自动化的,以方便此步骤。

步骤6-重构。

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

每个周期应非常短,一个典型的小时应包含许多周期。

红绿重构周期

这也通常称为“红绿重构”循环,其中-

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

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

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

TDD流程步骤

TDD过程的步骤如下所示。

TDD流程步骤

TDD的优势

测试驱动开发的优势或优势是-

  • 开发人员需要在创建代码之前首先了解所需的结果以及如何对其进行测试。

  • 仅当测试通过并重构代码后,组件的代码才结束。这样可以确保在开发人员进行下一个测试之前进行测试和重构。

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

  • 单元测试充当始终依赖数据的实时文档。

  • 如果发现缺陷,则开发人员将创建测试以发现该缺陷,然后修改代码,以便测试通过并修复缺陷。这样可以减少调试时间。所有其他测试也都运行,并且在通过时,可以确保不破坏现有功能

  • 开发人员可以随时做出设计决策并进行重构,并且测试的运行可确保系统仍在运行。这使软件可维护。

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

  • 在每个连续的测试运行中,还将验证所有先前的缺陷修复,并减少相同缺陷的重复。

  • 由于大多数测试是在开发本身中完成的,因此缩短了交付之前的测试。

TDD的缺点

起点是“用户故事”,它描述了系统的行为。因此,开发人员经常面临以下问题-

  • 什么时候测试?

  • 要测试什么?

  • 如何知道是否符合规格?

  • 该代码是否具有商业价值?

关于TDD的误解

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

Misconception Clarification
TDD is all about testing and test automation. TDD is a development methodology using Test-First approach.
TDD does not involve any design. TDD includes critical analysis and design based on the requirements. The design emerges during development.
TDD is only at Unit level. TDD can be used at the integration and system levels.
TDD cannot be used by traditional testing projects. TDD became popular with Extreme Programming and is being used in other Agile methodologies. However, it can be used in traditional testing projects as well.
TDD is a tool.

TDD is a development methodology, and after every new Unit Test passes, it is added to the Automation Test Suite as all the tests need to be run whenever a new code is added or existing code is modified and also after every refactoring.

Thus, Test Automation Tools supporting TDD facilitate this process.

TDD means handing Acceptance tests to the developers. TDD does not mean handing Acceptance Tests to the developers.

验收TDD

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

ATDD中的主要做法如下-

  • 讨论实际场景以建立对域的共享理解。

  • 使用这些方案得出接受标准。

  • 自动化验收测试。

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

  • 使用测试作为实时规范可以促进更改。

使用ATDD的好处如下-

  • 需求是明确的,没有功能上的差距。

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

  • 验收测试指导开发。

验收TDD

TDD与BDD

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

  • 从哪儿开始

  • 测试什么,不测试什么

  • 一口气测试多少

  • 什么叫他们的测试

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

解决所有这些问题的方法是行为驱动开发。它是从已建立的敏捷实践中演变而来的,旨在使团队更易访问和有效,这对于敏捷软件交付是全新的。随着时间的流逝,BDD逐渐发展壮大,涵盖了敏捷分析和自动验收测试的广阔前景。

TDD和BDD之间的主要区别在于

  • TDD描述了软件的工作方式。

  • 另一方面,BDD-

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

    • 促进协作与沟通。

    • 强调系统行为的例子。

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