为什么 BDD 在实践中很糟糕？

为什么 BDD 在实践中很糟糕？

对于外行来说，行为驱动开发 (BDD) 是一种软件开发方法，强调开发人员、测试人员和业务利益相关者之间的协作，以确保软件产品按照业务需求交付。

在实施 BDD 时，关键是要建立一种参与开发流程的各方都能理解的共同语言，以确保成功。这种共同语言是通过用小黄瓜语法编写的情景来传达的，它从终端用户的角度概述了应用程序应如何执行。这些方案采用简单的声明式语言编写，优先考虑应用程序应完成的任务，而不是如何完成。

通过创建 Gherkin 场景，BDD 有助于确保参与开发过程的每个人都能清楚地了解应用程序应该做什么以及在不同情况下应该如何运行。

虽然 BDD 承诺提供更高质量的软件产品，但在实践中，它可能是一种令人沮丧的体验--因为采用 BDD，嗯，糟透了。

问题

使用 BDD 首先要采用 BDD，如果使用不当，会给下游带来很多问题。

1、采用的困难

• 需求说明者（如产品经理）不采用 BDD 实践
• 开发人员在创建场景时没有贡献
• 质量保证部是唯一 "进行 BDD "的部门

如果团队或产品经理不愿意学习和适应 BDD 实践，以 BDD 格式编写需求可能会很耗时。

有些组织只让质量保证团队执行 BDD 实践。测试人员发现自己需要花费大量时间将需求转化为 BDD 格式，这既耗时又容易出错。如果测试人员是唯一使用 BDD 的利益相关者，这将导致净收益为零。我甚至会说这是净负效益，如下所示。

BDD 是一个协作过程，需要团队所有成员的参与，包括开发人员、产品经理和测试人员。如果开发人员或产品经理没有参与编写自动化代码或审核测试用例，他们可能无法完全理解测试用例的意图，从而导致本可避免的误解和错误。

2、方案的复杂性

• 使用命令式格式而非声明式格式编写方案
• 非确定性或容错系统可能难以用 Gherkin 表达
• 复杂的方案会产生复杂的自动化

命令式场景是如何测试特定功能的分步说明，而声明式场景则描述系统的预期行为。如果您能将一个场景展示给不具备系统专业知识的人看，他们应该能够理解该场景试图测试的特性或功能。

如果产品经理不参与这些场景的编写过程，那么这些场景往往是以命令式的方式创建的，除了测试人员自己，其他人根本无法读懂。

用 BDD 格式描述非确定性系统可能具有挑战性，因为它们并不总是以可预测的方式运行。测试人员可能很难想出能涵盖所有可能结果的方案，这可能导致测试不完整，漏掉产品经理在定义过程中可能已经了解的错误。

3、笨重的自动化

• 必要场景转化为必要步骤
• 自动化与功能耦合，不可重用
• 缺乏与需求工具的联系

BDD 在实践中面临的另一个挑战是编写可重复使用的自动化。BDD 场景的目的是实现自动化，但在创建这种自动化时，如果缺乏用心和适当的跑道，就会导致灾难。

在编写 BDD 方案时，我们会创建步骤定义来描述操作和断言。这些步骤定义的编写方式应便于在多个测试用例中重复使用。但是，如果公司不能有效地重复使用步骤定义，你就会发现功能之间的步骤定义之间有太多的复制粘贴。

如果自动化代码的编写方式经常需要不断重构步骤代码，导致难以维护和更新测试用例，那么它就会成为维护工作的噩梦，并导致工作效率下降。

最后，如果通常只有 QA 在编写这些方案，那么很可能与需求软件没有任何联系，从而造成可追溯性的噩梦。这通常会导致一个巨大的回归场景套件的运行，因为根本无法知道哪些需要测试，哪些不需要测试。

总结

当通过步骤进行的自动化可重复使用且可扩展时，BDD 对于验收测试驱动开发（Acceptance Test Driven Development）等项目来说是一种非常有用的方法；测试及其结果可追溯到需求工具--确保您的需求覆盖率。以更少的错误和更清晰的功能覆盖率发布产品的梦想。

问题是很多人只是简单地用错了。

BDD 并非灵丹妙药，需要团队所有成员通力合作才能取得成功。要避免我经历过的陷阱，重要的是要得到所有团队成员（包括产品经理、开发人员和测试人员）的支持，并投资于设计良好的自动化架构，以支持可重用性和可维护性。这样，企业就能收获 BDD 的好处，并交付满足客户需求的高质量软件。