HitchStory 是一个 BDD 工具吗？如何在 hitchstory 中进行 BDD？

BDD 有两个含义。我认为它们是冲突的

• 编写 Gherkin 并执行 Gherkin - 像 Cucumber、Behave、RSpec。
• 可以用于利益相关者协作的工具。

我创建 hitchstory 的主要动机之一是

1. 我相信编写一个工具，主要是让集成测试人员编写集成测试。

2. 我认为 Gherkin 使利益相关者协作变得更加困难，我想让它变得更容易。

BDD 是一个经常被误解的概念。在人们的心目中，它总是与 Gherkin 密切相关，但它从来都不是关于 Gherkin 的。

BDD 的真正含义是

1. 一种使用示例编写的场景来制作规范的方法。
2. 使用这些场景与利益相关者进行有关预期行为的对话。
3. 使用这些场景作为一种同意示例行为的方式。

也就是说，它是一种仅仅用于演进程序规范的方法。它从来不需要任何工具。它可以在餐巾纸的背面完成。

测试在 BDD 中处于什么位置？

基于示例的场景可以制作非常好的验收测试。一旦使用 BDD 规范的结果使用任何工具编写测试，你就不是在做 BDD，你可能是在做 ATDD（验收测试驱动开发）。

这两个可以结合起来，节省时间和重复工作，如果你不是使用纸笔或简短的 JIRA 描述，而是使用领域适当的场景语言。

可以使用一种语言来执行测试和与利益相关者达成预期行为，可以用来结合 BDD 和 ATDD。

BDD 和 ATDD 如何组合会出错？

我认为，使用 Gherkin，它通常会这样做。

• 如果你使用了一种难以阅读的场景语言。例如，如果一个程序主要使用 xUnit 测试进行测试，即使利益相关者能够理解这些场景，他们通常也无法阅读这些测试。

• 表达能力不强的场景语言。一种经常抽象化规范的重要细节或最终变得非常重复的语言，可能用于编写测试，但不能用于进行 BDD。这是 Gherkin/Cucumber 测试由于其结构和语法而导致的最常见的失败模式。

• 期望利益相关者想要编写场景语言。起草简明、清晰、明确的场景是一门艺术和一门技能，大多数人都不具备。它不是编程，但它比其他任何东西都更像编程。