为什么 hitchstory 强制使用 given 但不使用 when 和 then？

Given-When-Then 是一种编写测试用例或可执行规范的结构化方式。它由 Dan North 在行为驱动开发中发明。

霍尔逻辑

这种模式是一种结构，基本上所有测试用例都应该用它来编写，将前提条件与操作与可观察的结果分开。它遵循霍尔逻辑 - 一种严谨地推理计算机程序正确性的方法。

许多 BDD 框架都具有用于 given、when 和 then 的显式关键字。这些关键字旨在以“可读”的方式描述故事的结构。

但关键是，关键字实际上并没有做任何事情。例如，在 Cucumber 中，将“when”和“then”放在一起没有实质性区别 - 它们本质上是空运算符。

我认为它们类似于测试用例编写的“辅助轮” - 它们对初学者来说很有用，可以帮助测试人员保持正轨，确保创建的测试用例是有意义的并且真正进行了测试。

但是，虽然辅助轮对初学者来说很有用，但一旦不再需要它们，它们就会变得笨拙且碍事。

Hitchstory 认识到该模式描述了应该如何编写，但除了 given 之外，它既不要求也不鼓励使用实际的关键字。

简洁是 hitchstory 的一个关键原则 - 它的理念是故事应该尽可能短且不重复，只要不影响可读性即可。

例如，在这种情况下，“click”是“when”步骤，“goes kaboom”是 then 步骤。故事没有它们仍然很清楚。

given:
  box: red
steps:
- click: red button
- goes kaboom

尽管如此，如果你选择，你可以创建以 when 和 then 开头的步骤。

Given:
  I have: red box
Steps:
- When I click: the red button
- Then it goes kaboom