我现在正在开展一个项目，我们正在使用cucumber-jvm来推动验收测试。
在以前的项目中，我会在groovy或scala中创建内部DSL来推动验收测试。这些DSL使用起来相当简单，即使是非技术人员也可以通过一些指导来编写测试。
我看到BDD为测试添加了另一层间接和语义糖，但我没有看到增值，特别是如果非技术人员可以使用内部DSL。
在黄瓜的情况下，stepDefs似乎将驱动任何给定测试的代码分散到几个不同的类上，使得测试代码难以在特征文件之外读取和调试。另一方面，将所有与一个测试相关的代码放在一个stepDef类中，不鼓励重复使用stepsDefs。这两种结果都是不可取的，让我问自然语言的用途是否值得所有这些额外的，非直观的间接？
我有什么遗失的吗？就像ATDD和BDD之间微妙的哲学差异一样？前者是否意味着必要的测试，而后者意味着声明性测试？这些审美差异是否具有内在价值？
所以我还在问为什么是增加值来证明驱动测试的实际代码的可读性有所恶化。这个BDD的东西真的值得痛苦吗？这个价值增加的不仅仅是审美吗？
如果有人能够提出一个令人信服的论据，为什么BDD的获得超过BDD的痛苦，我将不胜感激？
答案 0 :(得分：2)
我看到BDD为测试添加了另一层间接和语义糖，但我没有看到增值，特别是如果非技术人员可以使用内部DSL。
额外的图层是普通语言.feature文件，在创建时它与测试无关，它与使用名为specification by example的技术创建系统要求有关。创建well defined stories。如果在业务语言中正确编写，则通过示例的规范在创建共享理解方面非常强大。仅此练习既可以减少返工量，又可以在开发之前找到缺陷。此练习也称为deliberate discovery。
一旦您对规范达成共识并达成一致，即可进入开发阶段并使这些规范可执行。这是您使用ATDD的地方。所以BDD和ATDD不具有可比性，它们是免费的。作为ATDD的一部分，您使用在故事中通过示例定义的行为来推动系统的开发。作为开发人员，您拥有的好东西是一种正式格式，包含可以自动执行的前置条件，事件和后置条件。
在此，CI系统上可执行规范的自动运行将减少回归，并为您提供从任何其他自动化测试技术中获得的所有好处。
这些非常有趣的事情是，可执行规范文件是长期存在的，随着时间的推移以及向系统添加/更改行为而不断发展。与大多数敏捷方法不同，用户故事在开发之后就会丢失，在这里您可以获得系统的实时文档，这也是规范，也是自动测试。
现在让我们通过健康的BDD启动交付流程（这不是唯一的方法，但这是我们喜欢的工作方式）：
因此，BDD可以真正帮助您解决大多数交付系统中缺失的部分，即规范部分。这通常是没有纪律和自由形式的，并且由几个人组成。这就是BDD是一种敏捷方法，而不仅仅是一种测试技术。
考虑到这一点，让我解决你的其他一些问题。
在黄瓜的情况下，stepDefs似乎将驱动任何给定测试的代码分散到几个不同的类上，使得测试代码难以在特征文件之外读取和调试。另一方面，将所有与一个测试相关的代码放在一个stepDef类中，不鼓励重复使用stepsDefs。这两种结果都是不可取的，让我问自然语言的用途是否值得所有这些额外的，非直观的间接？
如果您将stepDefs作为自动化测试代码库之上的超薄层，那么可以轻松地从多个步骤重用自动化代码。在测试代码库中，您应该使用testing pyramid和shallow depth of test等技术和原则，以确保您拥有强大而快速的测试自动化层。这种分离的另一个有趣之处在于它允许你在stepDefs和你的单元/集成测试之间篡改代码。
我有什么遗失的吗？就像ATDD和BDD之间微妙的哲学差异一样？前者是否意味着必要的测试，而后者意味着声明性测试？这些审美差异是否具有内在价值？
如上所述，ATDD和BDD是互补的，无法比较。在命令性/声明性方面，通过示例作为技术的规范是非常具体的。当你进行有意识的发现阶段时，你总是作为问题＆＃34;你能给我一个例子＆＃34;。在该示例中，您将使用精确值。如果有两个值可以在前置条件（给定）或事件（何时）步骤中使用，并且它们具有不同的结果（然后是步骤），则意味着您有两个不同的场景。如果结果相同，则可能是相同的情况。因此，作为BDD实践的一部分，这些步骤需要声明，以获得有意识发现的好处。
所以我还在问为什么是增加值来证明驱动测试的实际代码的可读性有所恶化。这个BDD的东西真的值得痛苦吗？这个价值增加的不仅仅是审美吗？
如果您在一个想要解决沟通错误问题的团队中工作，那是值得的。人们使用BDD失败的原因之一是因为功能的编写和自动化对于开发人员和QA而言是不可取的，并且工件不再像生活规范那样连贯，它们只是测试脚本。
测试脚本会告诉您系统如何处理特定事物，但它不会告诉您为什么。
如果有人能够提出一个令人信服的论据，为什么BDD的获得超过BDD的痛苦，我将不胜感激？
关于使用正确的工具来做正确的工作。使用Cucumber编写单元测试或自动化测试脚本就像使用锤子将螺钉拧入木材中。它可能会奏效，但它永远不会漂亮，而且总是很痛苦！
关于工具主题，您的典型业务分析师/产品所有者不会具备查看源代码管理所需的知识，并且可以在添加/修改规范时与您合作。我们创建了一个商业工具来解决这个问题，允许整个团队在云中进行规范协作，并与您的存储库保持同步（实时）。 Check out Simian
我也回答了一个关于BDD的问题，您可能会对此感兴趣，更关注开发：
答案 1 :(得分：0)
黄瓜和硒是两种流行的技术。大多数组织使用Selenium进行功能测试。这些正在使用Selenium的组织希望将Cucumber与Selenium集成在一起，因为Cucumber使其易于阅读和理解应用程序流程。黄瓜工具基于行为驱动开发框架，该框架充当以下人员之间的桥梁：
黄瓜也使客户理解应用程序代码，因为它使用纯文本格式的小金语言。组织中的任何人都可以了解软件的行为。 Gherkin的语法在易读易懂的简单文本中。