我想提出这个问题，因为这似乎是一些争论的焦点，我想知道社区对此的看法。
为了向您介绍我工作的团队的运作方式并给出一些背景信息，我们在一个名为“Three Amigos”的会话中为RESTful API编写黄瓜。三个Amigos基本上意味着将有一个技术主管，开发人员（一个或多个）和BA（一个或多个）参与充实故事的验收标准。作为本次会议的一部分，BA通常会为黄瓜编写小黄瓜。
这是一个开始的例子。如果我有一个RESTful API来获取有关汽车的信息，我可能会有一个场景说： -
Scenario: Engine size should appear in the car
Given a car exists
When I request the car
Then the car should have a "1700cc" engine capacity
或者你可以像
那样写Scenario: Engine size should appear in the car
Given a "Mazda/ModelABC" car exists with an engine capacity
When I GET "Mazda/ModelABC"
Then the response should contain "1700cc" engine capacity
现在我眼中的第一个更容易阅读，但不会促进代码重用（这是一个大问题吗？）。第二个促进代码重用，并且是从利益相关者（即开发人员）的角度编写的，但业务分析师（BA）不会这样写，因此它会使Three Amigos会话毫无意义。
鉴于两种方法是更强烈推荐的选择？在我的案例中，我选择了第一种方法，但我很想知道这两种方法的论点是什么，或者是否有一些体面的文章，人们可以提出建议，这表明应该采用哪种方法。
感谢。
答案 0 :(得分：2)
您可以在此答案的每个段落后面加上“恕我直言”。这是我在做BDD /规范四年后的经验。
BDD是关于沟通的。 BDD是在整个团队中相互理解。
Cucumber（只是）一种促进沟通的工具。使用Cucumber（以及它添加的额外抽象）的唯一原因是因为它会比其他格式更容易理解彼此。 如果我们只是团队中的开发人员，我们可能会更好地使用代码。
因此，要回答您的问题，如果您的BA和客户了解GET，POST等，那么在规范中使用它可能是合适的。但请注意，您只是将规范与实现联系起来。变化甚至会传播到Cucumber场景中。
更有可能的是，您的第一个示例是您的客户和BA可以直接关联并理解的格式。
但是，当然，这取决于非技术团队成员使用的技术细节水平。让每个人都能轻松理解。
BDD是关于沟通的。
这里有一些关于这个主题的演讲，我发现它既有用又有一个非常有趣的话题：