我在BDD场景中有多具体？

Question

采用两种不同的方式陈述相同的行为。

选项A：

Given a customer has 50 items in their shopping cart
When they check out
Then they will receive a 10% discount on their order

选项B：

Given a customer has a high volume of items in their shopping cart
When they check out
Then they will receive a high volume discount on their order

前者更具体。如果有人对客户获得大量折扣的确切时间或提供多少折扣有疑问，那么阅读这种情况就会非常清楚。服务于记录行为的目的，尽可能具体，尽管这些值的任何变化都需要改变方案。

第二个更概括，并没有第一个的清晰度。自动化它需要在步骤实现中合并值“50”和“10”。另一方面，该方案捕获了核心业务需求：大批量客户获得折扣。如果我们后来决定使用“40”和“15”，那么场景不必改变，因为核心业务需求并没有真正改变（尽管步骤实现会）。此外，“大批量客户”一词也说明了为什么我们给他们折扣。

那么哪个更好？相反，在什么情况下我应该支持前者还是后者？

Answer 1

我想我会选择A。

问题是BDD场景必须作为系统的文档。

因此，如果非技术人员想知道您的折扣系统是如何运作的（业务人员，测试人员或来自客户支持团队的人员），他们肯定想知道拥有大量商品的意义。什么是应用折扣。 并且他们不希望必须使用管道代码来获取此信息。

我认为这些信息很重要，不能向读者隐瞒。

另一个好处是，它允许非开发人员（例如测试人员）编写新方案，并检查如果购物车中有1件商品或100件商品会发生什么。

如果你对事物有太多的抽象，那么应用有意识的发现会变得更加困难。 因此，对于选项B中的方案，您没有机会向自己询问这些问题：

• 如果我们有超过50个项目，如100个项目，那么会发生什么其他折扣
• 如果我们有1件商品会发生什么，我们不需要申请折扣，或者我们应该根据购物车的总价而不是商品的数量来申请折扣，有人只购买一件非常贵的商品应该也有折扣吗？
• 是唯一可用的折扣类型的10％，我们有固定金额折扣吗？我们有更复杂的折扣策略吗？

当业务变量可见时，您可以使用它们并找出您可能已经忘记的内容或考虑新的有趣（或不是）新功能。

作为一般规则，我会隐藏在场景中无关紧要的内容，在这种情况下，项目数量和应用的折扣值对读者来说真的很重要。