为什么使用 Hitchstory 而不是 Behave、Lettuce 或 Cucumber (Gherkin)？

HitchStory 和 Gherkin 都是用于编写用户故事的 DSL，这些故事可以充当验收测试，但它们有截然不同的方法和理念。

Gherkin 主要强调 用“面向业务”的文本编写的功能文档的执行.

设计者坚持认为它主要不是一个集成测试框架。

而 hitchstory 主要构建为一个集成测试框架，具有

• 使用 严格类型的 YAML 来定义规范以确保可读性、精确性、清晰度、简洁性和易于维护。

• 精确地指定所有行为，而不仅仅是“面向业务的文本”，但仍然强制执行 测试关注点分离.

• 规范文档测试三元组，以便自动生成文档并测试规范。

Gherkin 做对了什么

Cucumber 及其相关工具之所以流行是有原因的，即使它们犯了许多错误。 他们也做对了许多不明显的事情

• 强调规范的可读性 - xUnit 测试通常不擅长这一点。

• 规范应该充当测试的理念。

• 故意使用更简单的非图灵完备语言进行规范。

• 应该存在关注点分离。

• 内置参数化。

示例：Gherkin 与 HitchStory

从 训练轮脱落 Aslak Hellesøy 描述了 Cucumber 如何被用来编写测试（在他看来，很糟糕）

Scenario: Successful login
  Given a user "Aslak" with password "xyz"
  And I am on the login page
  And I fill in "User name" with "Aslak"
  And I fill in "Password" with "xyz"
  When I press "Log in"
  Then I should see "Welcome, Aslak"

以及他认为故事应该如何编写

Scenario: User is greeted upon login
  Given the user "Aslak" has an account
  When he logs in
  Then he should see "Welcome, Aslak"

因此，“不感兴趣的细节”被推送到步骤层，并且更难共享步骤代码。

由于 Gherkin 的语法 抑制了复杂规范的表达，该框架某种程度上鼓励了这种 向下关注点泄漏.

使用 HitchStory，大多数故事应该看起来像这样

Aslak sees welcome message on login:
  steps:
  - visit: /login
  - fill form:
      username: Aslak
      password: xyz
  - click: log in button
  - should contain:
      item: welcome banner
      message: Welcome, Aslak

从这个目标生成针对特定利益相关者的文档，这些利益相关者可能会剔除规范中“不感兴趣”的部分。

试图成为一种类似英语的语言

英语很模糊。英语很冗长。英语很乱。英语不精确。这些对于某些目的来说是理想的品质，但它们不适合编写规范。

就像实际代码一样，为了有效，规范必须精确、准确且 DRY。即使是非可执行规范也可以从这些品质中受益。

英语的不精确性在 Gherkin 规范中得到体现，部分原因是它缺乏继承性。这会导致模糊的故事 - 它们通常缺乏精确性和关键细节，最终充当程序所描述内容的高级描述。

解析器地狱

#

有些人遇到问题时会想，“我知道了，我会使用正则表达式。” 现在他们有两个问题了。 - Jamie Zawinksi

由于语言的英语化本质，解析也变得困难。Gherkin 需要非常

网络上有很多关于它出错的例子，给 Cucumber 用户带来了很多头痛，并经常导致数小时不必要的调试和 变通方法。

语法歧义的一个方面是，一些解析器要求你编写正则表达式来解析 Gherkin 的部分内容。

Given/When/Then 是不会脱落的训练轮

BDD 强调使用 Given、When 和 Then 来构建基于示例的测试用例。

而且，公平地说，几乎每个测试用例都应该遵循这种模式。但是，这些关键字对于解析器没有任何意义，会被忽略。

因此，HitchStory 提倡使用 Given/When/Then 模式，但除了 'given' 之外，不使用这些关键字。“Given” 是任意 YAML 的用户定义映射，可以用来配置 set_up 的行为，而故事的核心在于步骤。

given: something: something else steps: - step 1 # when - step 2 # then - step 3 # and - step 4 # but

冗长

为什么上面提到的这一点很重要？它会导致可执行规范，这些规范天生更简洁，并且以更少的文本提供更多信息 - 关于你的故事。

上面提到的 Given/When/Then 关键字的多样性带来的副作用之一就是更冗长。

弱类型/字符串类型

类型安全是编程语言的关键特性。虽然类型系统可能会对代码过于挑剔，以至于影响生产力，但总的来说，更高的类型安全性会导致更少的错误和更高的代码信心。这就是 TypeScript 优于 JavaScript，或 Rust 优于 C++ 的原因之一。

另一方面是“字符串类型”代码 - 最弱的类型系统，其中所有内容都是字符串。Bash 和 Makefiles 都是字符串类型，虽然对于简短的简单脚本来说还可以，但当这些脚本变得非常庞大时，调试会变得很痛苦。

Gherkin 是 字符串类型。步骤被解析（通常使用正则表达式），字符串被提取出来并被馈送到步骤代码中。

另一方面，HitchStory 基于 StrictYAML，并内置了基于模式的解析。

没有继承

#

"简短的回答，不。特性文件不能从另一个特性文件继承。" - Stack Overflow

继承一直以来都是关于保持代码 DRY 的。这是一个棘手的工具，因为它可以减少重复，但也会牺牲可读性。因此，Gherkin 舍弃了它。

来自 Stack Overflow 问题的

"一个常见的背景是在系统中登录。登录很重要，但它经常被隐藏在步骤中。"

这又是向下关注泄漏。

导致登录的步骤是系统规范的一部分，那么为什么要隐藏它呢？

保持步骤 DRY 和不隐藏步骤中的有意义细节之间的冲突，使 Cucumber 用户处于困境。

在文章 如何在 Cucumber 场景中避免重复 中，有几种尝试避免重复的方法，但没有一种特别有效。

可执行规范并不总是适合非技术人员

谈论音乐就像跳舞谈论建筑一样。-- Marvin Mull

大多数被测试的软件包实际上并不与人类交互，而是与其他软件交互。

这种交互可以通过代码进行 - 在这种情况下，规范应该用代码片段来定义。

这种交互可能是通过 REST API 进行的 - 在这种情况下，为了能够定义交互，你必须理解和定义 REST API 的语义，并且能够在定义规范时将其写出来。

规范不应该试图掩盖或简化这些细节。

公平地说，这不是 Gherkin 的语法或 Cucumber 的设计问题 - 它主要是文化影响。

即使利益相关者不感兴趣，它也应该对开发人员或测试人员有用

由于上述所有问题，Gherkin 在开发人员中没有得到广泛采用。

对于其他形式的配置，开发人员并不排斥使用专门简化的语言。

如果程序员不喜欢使用与他们的代码交互的工具或技术，那就别指望让业务使用它。