我看到的是 BDD 为测试添加了另一层间接和语义糖，但我看不到附加值，尤其是在非技术人员可以使用内部 DSL 的情况下。
额外的层是纯语言.feature文件，在创建时它与测试无关，它与使用称为通过示例规范的技术创建系统需求有关，以创建定义良好的故事。当用业务语言正确编写时，通过示例进行规范在创建共享理解方面非常强大。仅此一项练习既可以减少返工量，又可以在开发开始之前发现缺陷。此练习也称为故意发现。
一旦您对规范达成共识并达成一致，您就可以进入开发阶段并使这些规范可执行。这是您将使用 ATDD 的地方。所以 BDD 和 ATDD 没有可比性，它们是互补的。作为 ATDD 的一部分，您使用故事中通过示例定义的行为来推动系统的开发。作为开发人员，您拥有的好处是包含可以自动化的前置条件、事件和后置条件的正式格式。
在这里，可执行规范在 CI 系统上的自动运行将减少回归，并为您提供从任何其他自动化测试技术中获得的所有好处。
这些真正有趣的事情是可执行规范文件是长期存在的，并且随着时间的推移以及您向系统添加/更改行为而发展。与大多数敏捷方法中的用户故事在开发后就被丢弃不同，这里有一个系统的活文档，这也是规范，也是自动化测试。
现在让我们运行一个健康的支持 BDD 的交付过程（这不是唯一的方法，但它是我们喜欢的工作方式）：
- 故意发现会话。
- ATDD 推动发展
- 持续集成
- 自动化部署
- 衡量和学习
- 输出 = 为下一次深思熟虑的发现会议提供新的想法和反馈
因此，BDD 可以真正帮助您解决大多数交付系统中缺失的部分，即规范部分。这通常是无纪律和自由形式的，由几个人共同维持。这就是 BDD 是一种敏捷方法而不仅仅是一种测试技术的原因。
考虑到这一点，让我来解决您的其他一些问题。
在黄瓜的情况下，stepDefs 似乎将驱动任何给定测试的代码分散在几个不同的类中，使得测试代码难以在特性文件之外阅读和调试。另一方面，将与一个测试相关的所有代码放在单个 stepDef 类中会阻止对 stepDef 的重用。这两种结果都是不可取的，让我问，自然语言的使用有什么值得这些额外的和不直观的间接的？
如果您在自动化测试代码库之上使 stepDefs 成为一个超薄层，那么很容易重用来自多个步骤的自动化代码。在测试代码库中，您应该利用测试金字塔和测试的浅深度等技术和原则，以确保您拥有一个健壮和快速的测试自动化层。这种分离的另一个有趣之处在于它允许您在 stepDefs 和单元/集成测试之间使用代码。
有什么我想念的吗？就像 ATDD 和 BDD 之间的微妙哲学差异一样？前者是否意味着命令式测试，而后者意味着声明式测试？这些审美差异有内在价值吗？
如上所述，ATDD 和 BDD 是互补的，没有可比性。在命令式/声明式方面，作为一种技术的示例规范是非常具体的。当你在进行深思熟虑的发现阶段时，你总是会问“你能给我一个例子吗”。在该示例中，您将使用精确值。如果有两个值可以在前置条件（Given）或事件（When）步骤中使用，并且它们具有不同的结果（Then 步骤），则意味着您有两种不同的场景。如果结果相同，则很可能是相同的情况。因此，作为 BDD 实践的一部分，这些步骤需要是声明性的，以获得有意发现的好处。
所以我要问的是，为了证明驱动测试的实际代码的可读性恶化，增加了什么价值是合理的。这种 BDD 的东西真的值得痛苦吗？增值不仅仅是审美？
如果您在一个想要解决沟通不畅问题的团队中工作，那么这是值得的。人们使用 BDD 失败的原因之一是功能的编写和自动化留给了开发人员和 QA，并且工件不再像活的规范一样连贯，它们只是测试脚本。
测试脚本会告诉您系统如何执行特定操作，但不会告诉您原因。
如果有人能提出一个令人信服的论点来说明为什么 BDD 的收益超过了 BDD 的痛苦，我将不胜感激？
这是关于使用正确的工具来完成正确的工作。使用 Cucumber 编写单元测试或自动化测试脚本就像用锤子将螺丝钉入木头。它可能有效，但它从来都不漂亮，而且总是很痛苦！
在工具方面，您的典型业务分析师/产品负责人不具备窥探源代码控制和与您一起添加/修改规范所需的知识。我们创建了一个商业工具来解决这个问题，它允许您的整个团队在云中就规范进行协作并与您的存储库保持同步（实时）。看看四面。
我还在这里回答了一个您可能感兴趣的关于 BDD 的问题，该问题更侧重于开发：
TDD和BDD应该结合使用吗？