2

我想提出这个问题，因为这似乎是一些争论的焦点，我想知道社区对此的看法。

为了让您了解我所在团队的运作方式并为这个问题提供一些背景信息，我们正在为一个名为“三个朋友”的会话编写一个 RESTful API 的黄瓜。三个朋友基本上意味着将有技术主管、开发人员（一个或多个）和 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) 不会这样编写，因此这会使三个朋友的会议变得毫无意义。

鉴于这两种方法，哪个是更强烈推荐的选择？在我的案例中，我选择了第一种方法，但我很想知道这两种方法的论点是什么，或者是否有一些体面的文章可以支持这些建议，这表明应该真正使用哪种方法。

谢谢。

4

1 回答 1

2

您可以在此答案的每个段落之后加上“恕我直言”。这是我在做 BDD / Specification 四年后的经验。

BDD 是关于沟通的。BDD 是关于在整个团队中相互理解。

Cucumber（只是）一种促进交流的工具。使用 Cucumber（以及它添加的额外抽象）的唯一原因是因为它比其他格式更容易相互理解。如果我们只是团队中的开发人员，我们可能会更好地使用代码。

因此，要回答您的问题，如果您的 BA 和客户了解 GET、POST 等，那么在规范中使用它可能是合适的。但请注意，您只是将规范与实现联系起来。更改甚至会传播到 Cucumber 场景中。

您的第一个示例更有可能是您的客户和 BA 可以直接关联和理解的格式。

但是，当然，这取决于您的非技术团队成员使用的技术细节水平。让大家容易理解。

BDD 是关于沟通的。

这里有一些关于这个主题的演示，我发现它们既有用又在一种情况下非常有趣：

于 2013-09-05T17:41:58.287 回答