当自然语言模棱两可时，行为驱动开发如何提高清晰度？

9

我目前正在探索诸如黄瓜之类的BDD测试框架，当有人说时我感到很好奇

由于功能文件使用简单的自然语言，因此可以提高清晰度并提供清晰的视野

但是，自然语言难道不是我们在软件工程中遇到的大多数麻烦的原因吗？

自然语言是模棱两可的，这就是许多软件项目由于对客户需求和开发人员的理解的错误理解而失败的原因。我没有在这里的利基。

是的，将测试分解为微小的简单可行的操作是有意义的，并且可以提供一定程度的清晰度，但这是否可以整体上提高生产率？

PS：我不是专家，在这里也没有发表意见。我很好奇理解这个概念。

bdd cucumber

— Raghuram8892
source

1

很好的问题。我必须说，我从未见过像黄瓜在实践中提出的那样的事情。自然语言不适用于精确的技术任务，例如指定测试。

— 安德列斯F.

BDD对语言的使用旨在反映业务领域的现有语言，这对于企业来说应该已经是明确的了。Wikipedia文章确实在文本的开头指出了这一点。

— Martin Spamer

8

你是对的。BDD不能消除语言歧义性的问题-一点也不。正如其他人指出的那样，翻译后的代码片段需要通过适当定义它们来进行匹配，但这也不能解决潜在的歧义问题。

现在，尽管未解决此问题，但为什么BDD实际上值得？出于某些原因，此列表当然并不完整。

歧义尚未解决

这既不是支持BDD的理由，也不是反对BDD的理由。但是，当您将其与其他方法（例如用户故事或需求）进行对比时，所有软件开发方法都会遭受语言歧义的困扰，因为它们都以自然语言形式以一种或另一种方式开始。

从技术上讲，语言歧义性问题已通过诸如lojban之类的人工语言解决了，但话又说回来，您的客户和开发人员很可能不知道该语言。

无处不在的语言

BDD与无处不在的语言的想法紧密相关。能够与所有客户，测试人员和开发人员一起指定方案，这使BDD优于其他方法。

考虑一位传统的需求工程师写下所有需求。一旦您成为测试人员或客户，便获得了300页的文档，其中包含要审核的所有要求，那么您所面临的问题将比那里使用的术语还要紧。

用户故事在这方面做得更好，因为它们在创建过程中也包括了所有利益相关者。就普遍使用的语言而言，我不会说BDD或用户案例都更好-尽管它们在下一点确实有很大的不同。

可测性

BDD的一个主要方面是您的规范实际上是可执行的（通过Cucumber等）。需求和用户案例都没有提供此功能。对我个人而言，这是BDD的主要卖点。

与传统需求相反，我们已经告诉需求工程师很多年了，他们的需求应该是可测试的。但是，每个项目都会看到这样的情况：测试人员意识到某个地方不知道如何测试特定需求。

如果操作正确，则用户故事可以在早期创建阶段就包括测试人员，以确保这一点。不幸的是，这是一个理论与现实世界发生冲突的案例，在那里我看到了许多测试人员从未见过的故事。

另一方面，BDD会自动为您提供可执行的测试方案。没有任何借口，也没有办法解决（除非您完全忽略自动化层，并写下奇特的诗歌场景）。

一般而言，“测试优先”是在软件开发的所有阶段都非常有价值的原则，而BDD是其在开发的最外层的应用（与单元级别的f.ex. TDD相比）。

摘要

总之，BDD不会使您摆脱自然语言歧义的问题。但是，它确实可以通过两个要点来帮助您解决该问题：专注于一种普遍存在的语言以减少歧义（它不会完全消除歧义，但是会大有帮助！），以及通过迫使您编写可执行文件规格。后一点有助于解决歧义问题，主要是因为这是歧义开始以其他方式出现的问题。

— 坦率
source

这是一个了不起的答案。我问了这个问题后做了一些研究，我应该同意您的大多数观点。使用诸如黄瓜之类的工具或任何BDD工具的一个主要问题是开发人员在禅宗水平上不了解BDD的想法。。这是伊丽莎白·基奥（Elizabeth Keogh）的一篇有趣的文章。

— Raghuram8892

4

当用“自然语言”写东西时，可能意味着很多事情：

这实际上是英语。由于英语是一种非常模棱两可和不精确的语言，因此这种输入模式在软件开发的环境中并不令人满意。
这是英语，但相关术语已明确定义。这种语言用于法律文件或数学课本中。
这是一种形式语言，但是该语言是按照自然语言的约定非常紧密地建模的。这在某种程度上描述了所有编程语言。正式语言越像英语，对未经培训的读者来说越容易理解。达到此目标的编程语言的著名示例包括COBOL和SQL：select id, name from persons where age > 18显而易见。这些语言的缺点是您确实需要了解正式语言才能编写有效的代码。而且，这些语言通常非常冗长。

DDD建议该项目使用一种普遍使用的语言来描述领域。本质上是情况2：定义相关术语，以便您可以在自然语言中进行精确交流。

黄瓜本身就是情况3：一种旨在阅读非常接近普通英语的正式语言。更准确地说：Cucumber是一个框架，允许您定义一种简单的形式语言，该语言可用于表达需求/测试。这里的要点是，同一文档代表自然语言要求和自动可执行的测试，因此两者始终保持同步。您可以阅读一个黄瓜方案，并验证它能正确表达您的要求，而不必了解所有方案的工作原理。

黄瓜的工作方式是将文档与已知的自然语言片段进行匹配。这些片段必须首先定义。要使用Cucumber编写方案，您需要了解可用的代码片段-该软件不会引起您的注意。这些代码片段也可能引起问题：当您实现文本代码片段的行为时，您的代码可能会执行与代码片段文本所建议的稍有不同的操作。如果多次使用相同的代码段，则这不太可能成为问题。因此，黄瓜非常适合描述由较小的一组条件，操作和结果组成的业务规则。如果每个代码段仅使用一次或两次，则其他测试框架可能会更好，例如，因为每个测试用例的设置都是唯一的。

— 阿蒙
source

感谢您的详细信息。我觉得在情况2和情况3之间，黄瓜在某种程度上处于灰色区域。它与SQL不同，在SQL中，您实际上不能拥有某种“自由意志”，并且坚持严格的形式语法。据我所知，黄瓜在场景的“给定”，“何时”关键字之后不允许使用任何形式的文本吗？可能就这么简单，但是我来自一个非英国籍的国家，这个国家很可能很难让人给出准确的摘要。

— Raghuram8892

1

是的，您可以在Given/ When/ 之后加上任何内容Then，但a）您和您的团队精确定义了这意味着什么，b）您在匹配器中使用代码（即形式语言）定义了含义。

— 约尔格W¯¯米塔格

0

@ Raghuram8892，Given / When / Then / And关键字后的文本必须与“代码段”匹配，否则该步骤将失败，因为未定义或“待定”。因此，它正好落入案例3。

关于“英语”，黄瓜及其语言，小黄瓜是专为国际使用而设计的。您可以调用该命令，cucumber --i18n help以查看当前支持的语言列表，并cucumber --i18n $CODE查看特定语言代码的关键字。例如，cucumber --i18n eo给出世界语的关键字。

— 脆皮
source