automated-tests - 当团队不练习 bdd 时，黄瓜的真正好处是什么？

BDD 是一种很棒的软件开发方法，我们都知道。但我们通常看到的是将 BDD 误解为 Cucumber/任何其他将 Gherkin 带入项目的测试自动化工具。

话虽如此，在一个拥有 QA 的团队自动化后端和前端测试而其他成员（开发人员、PO、BA）不使用 bdd 的情况下，使用这样的工具带来的真正好处是什么有吗？

我一直在尝试继续使用它，但有几次它似乎需要更多的维护工作，因为包含小黄瓜语言的功能文件需要一个额外的层。

标签： automated-testscucumberbddqagherkin

文化至上的概念说，如果一个人想要实现其（组织）目标，他/她应该从人开始，然后转向流程并最终采用正确的工具。

我大部分时间都在需要基于 Cucumber 的测试工具的公司工作，但这都是货物崇拜。换句话说 - 黄瓜框架是测试自动化的负担，没有服务于行为驱动的开发过程。最顶层 2 层（小黄瓜和台阶/胶水）的维护对团队来说具有零（甚至负）的经济价值。

我们确实尝试让智能测试人员参与进来（我不同意“手动 QA”一词）来帮助场景的早期创建，但由于他们使用命令式 Gherkin，因此没有成功。使用 Cucumber 进行测试的自动化依赖于声明性语言。

以完整答案为目标 - 并不真正需要单独的步骤和DSL层，如“最佳”实践中所述。

您可以简单地将 Step 函数/方法用作 DSL，并在其他地方引用/调用它们。