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％，我们是否有例如固定金额的折扣？我们有更复杂的折扣策略吗？

当业务变量可见时，您可以玩弄它们并找出您可能已经忘记的东西或想到新的有趣（或不）功能。

作为一般规则，我会隐藏在场景中知道的并不重要，在这种情况下，项目的数量和应用的折扣值对读者确实非常重要。