为什么HitchStory不表达对“业务”感兴趣的内容的观点？

当Cucumber最初获得一些流行度时，原始开发人员有一些反弹，认为用户 "没有正确使用它"

具体的抱怨是它被用作集成测试框架，而不是用于“与业务沟通”的工具，并且除了高级的“业务需求”之外的所有内容都应该被抽象化。

HitchStory采取了不同的方法，建议将其用作集成测试框架主要，并使用 文档生成工具 在必要时从这些工具中生成文档，这些文档对于利益相关者而言具有适当的详细程度。

这是因为

• 从BDD的角度来看，“业务”是一个假设的实体，实际上并不存在。有不同类型的利益相关者 - 许多不同的人对规范的不同部分有不同的兴趣程度。

• 利益相关者很少对实现细节感兴趣，他们只对规范的某些方面感兴趣。

• 利益相关者对软件行为细节的兴趣会大相径庭。有时他们只希望模糊的细节，有时他们会对模糊的业务逻辑感兴趣，有时他们会对特定的用户界面操作感兴趣。

• 兴趣因利益相关者而异 - UX设计师、UI设计师、翻译人员、产品经理和CEO对软件行为细节的兴趣程度都会有所不同。

• 最适合指定代码的语言不一定英语或类似英语的语言。

尽管如此，尽管有这一切，Cucumber的人们还是有所发现的 - 文档和规范之间存在着紧密的联系。

HitchStory的观点是，所有行为都应该由用户故事指定，以及任何适当的元数据，并且应该生成文档。