为什么 HitchStory 使用 StrictYAML？

YAML 被经常批评，而且确实如此。

HitchStory storytests 使用 StrictYAML 编写的三个原因

它强制在你的声明式规范和命令式测试代码之间分离关注点。
storytests 可以被编程为从程序输出重写自身，这使得快照测试驱动开发变得容易。
storytests 可以用作模板来生成漂亮的 markdown 文档 - 这使得文档驱动开发变得容易。

然而，如果 storytests 使用普通的 YAML 解析器进行解释，这些功能都没有用。

当我第一次构建 hitchstory 时，当我尝试用 pyyaml 构建它时，我一头撞进了所有这些问题 - 字符串随机地变成数字，错误的缩进会导致令人困惑的错误。我的工作经历了我后来称之为挪威问题。我感受到了对 YAML 的厌恶。

但是，我仍然喜欢 YAML 的外观。YAML 的核心仍然是一个非常干净、美观的格式。它只是一些可怕的、不必要的特性，急需类型安全性。

这就是我构建StrictYAML的原因。虽然我是为了构建 hitchstory 而构建它的，但它本身就变得流行起来。

使用 hitchstory，我可以编写满足以下条件的规范：

100% 声明式。
清晰地显示复杂的分层数据（例如，向 REST API 故事添加所需的请求头会很容易）。
具有最小的语法噪声。
清晰地显示多行字符串。
对大多数人来说看起来很熟悉。
可以与现有的语法高亮器一起使用。

然而，如果它不安全地编辑，因为一个单引号或错误的缩进会导致 20 分钟的调试，所有这一切都是毫无意义的。因此，StrictYAML 的存在成为 hitchstory 的必要先决条件。

使用 HitchStory，用户故事的核心结构是固定的，但元数据、前提条件和步骤需要用户定义的迷你模式才能处理比字符串更复杂的内容。以下是一个验证解释 REST API 请求和响应的步骤的示例：https://github.com/hitchdev/hitchstory/blob/master/examples/restapi/tests/test_integration.py#L35（查看 @validate 中的所有内容）。

避免构建 YAML 编程语言

Ansible 是 hitchstory 的灵感来源，因为我第一次看到它时，我就看到了它的 YAML 运行手册有多么干净、易用和可读。

然而，我也看到了这些运行手册变得复杂时会发生什么。

Ansible 陷入了我称之为“图灵完备陷阱”的陷阱 - 配置语言最初很好，然后在尝试解决特定问题后，意外地变得图灵完备。导致这种情况的典型特性是条件语句和循环。

但是，这些 YAML 语言不是好的编程语言，当你尝试调试它们时，这一点尤其明显。

一些持续集成 YAML 工具也落入了图灵完备陷阱，调试它们也可能很痛苦。

HitchStory **永远不会**在规范语言中实现条件语句或循环。测试引擎在解释规范时需要条件语句和循环，但规范本身永远不会实现它们。