𝟯 𝗧𝗵𝗶𝗻𝗴𝘀 𝗡𝗼𝗯𝗼𝗱𝘆 𝗧𝗲𝗹𝗹𝘀 𝗬𝗼𝘂 𝗔𝗯𝗼𝘂𝘁 𝗕𝗗𝗗

Your Cucumber suite takes forty minutes to run. You cannot explain what a single feature file tests without reading layers of code.

Many teams adopt BDD because business stakeholders need to read tests. Then, those stakeholders stop reading. You end up with a maintenance nightmare.

Here are three truths about BDD.

𝟭. 𝗚𝗵𝗲𝗿𝗸𝗶𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲

Stop writing test scripts in Gherkin. If your scenarios list every click and every field, you are doing it wrong.

Bad Gherkin:

  • Given the user enters email "test@example.com"
  • And the user enters password "Password123!"
  • And the user clicks "Place Order"

Good Gherkin:

  • Given the user has items ready to purchase
  • When the user pays with a valid credit card
  • Then the order is confirmed

The "how" lives in your step definitions. The "what" lives in your feature files. Keep your feature files simple so a product manager can read them in seconds.

𝟮. 𝗦𝘁𝗲𝗽 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗮 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗴𝗿𝗮𝗽𝗵

Do not make step definitions import other step definitions. This creates a tangled web. If one step fails, it poisons the entire state.

The fix is simple:

  • Separate your page objects from your step definitions.
  • Use a shared domain layer.
  • Step definitions should be thin wrappers that call domain objects.

This makes your steps stateless. You can change one part of your code without breaking every other scenario.

𝟯. 𝗕𝗗𝗗 𝗶𝘀 𝗮 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁

BDD is about communication, not just testing. The tests are a side effect.

If you optimize only for test coverage or execution speed, you lose the main goal. Your feature files should be the first thing a new engineer reads to understand your system.

If a person cannot understand your system by reading your feature files, your BDD suite has failed.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄:

  • Pick your worst feature file.
  • Rewrite scenarios to be three to five lines long.
  • Move data into step definitions or factories.
  • Replace step-to-step imports with domain objects.

Can you explain your system to a new hire using only your feature files in five minutes? If not, start rewriting.

在你的 Cucumber 测试套件变成维护噩梦之前，没人告诉你的关于 BDD 的 3 件事

BDD（行为驱动开发）通常被宣传为连接业务需求与技术实现之间的终极桥梁。它承诺通过使用人类可读的语言（Gherkin）来消除沟通隔阂，让产品经理、开发人员和测试人员在同一个语境下工作。

但对于许多团队来说，BDD 并未带来更好的协作，反而导致了一个庞大且难以维护的测试套件，让每个人都对其望而生畏。

在 BDD 变成噩梦之前，有三件事是没人告诉你的。

1. Gherkin 陷阱：编写的是“如何做”而非“做什么”

最常见的错误是编写“指令式”（Imperative）的 Gherkin。

错误示例（指令式）：

Given I am on the login page
And I enter "user@example.com" in the email field
And I enter "password123" in the password field
And I click the "Login" button
When I click the "Submit" button
Then I should see the dashboard

正确示例（声明式）：

Given I am a logged-in user
When I access the dashboard
Then I should see my account details

指令式的 Gherkin 非常脆弱。如果 UI 发生了变化（例如，按钮变成了链接，或者输入框的 ID 变了），你的测试就会失败。

声明式的 Gherkin 则专注于意图和结果，这使得它在面对 UI 变化时具有更强的韧性。

2. 步骤定义爆炸 (Step Definition Explosion)

当你编写指令式步骤时，最终会产生一个庞大的步骤定义库，这些定义几乎完全相同，却又存在细微差别。

例如：

  • I click the login button
  • I click the submit button
  • I click the sign-in button

这会导致“步骤定义爆炸”，使得寻找正确的步骤变成了一件苦差事，而添加新步骤则变成了一种沉重的维护负担。

3. 沟通鸿沟：它只是“昂贵的文档”

关于 BDD 最大的谎言是它能“自动”改善沟通。

如果你的产品负责人 (PO)、业务分析师 (BA) 或利益相关者实际上并不阅读、审查或协助编写 Gherkin 场景，那么你并没有在做 BDD。

你只是在使用一种非常冗长、人类可读的语法编写自动化测试。在这种情况下，BDD 变成了“昂贵的文档”——需要不断的维护，却无法提供任何业务价值。

结论

BDD 是一个强大的工具，但前提是必须正确使用。

专注于声明式场景，保持步骤定义的复用性，最重要的是，让业务方真正参与到流程中来。

Source: https://dev.to/qawalah/3-things-nobody-tells-you-about-bdd-before-your-cucumber-suite-becomes-a-maintenance-nightmare-9c7

Optional learning community: https://t.me/GyaanSetuAi