在空手道中，我们如何与 BA 协同工作以自动化业务场景
In Karate how we can collaboratively work along with BA to automate business scenarios
在使用 Karate 时，我们能够对 Web 服务进行大部分验证，我们能够成功地将 Karate 与 Selenium webdriver 集成，并使用 java 类 进行数据库断言。对于数据库，我们通过将每一行转换为哈希图将结果集返回为列表，而空手道将其作为 json 数组。所以验证变得简单。我们在 QA 方面的大部分需求都已使用 Karate 实现。
但是，今天我们向更大的社区介绍它时，其中一位开发负责人提出了一个问题。他是 JBehave、BDD、jsonpath、java、Web 服务等方面的专家。根据我们的上下文，我们也认为他的问题确实相关。但是，空手道的方法不同，据我们所知可能行不通。
在我们的上下文中，我们需要让 BA 使用业务术语考虑他们的业务场景来编写 BDD，QA/Dev 稍后可以将它们转换为脚本。 （我们通常使用黄瓜 + selenium/rest assured 等方法）。例如，如果我有一个特征文件和10个场景，业务方面的人将不会理解验证的细节看到的步骤在空手道/或换句话说，纯英语文本对他们来说会更容易理解。我们需要这种方法，因为我们试图从故事层面本身实施流程变更。
能否分享一下您的想法？
简短回答：空手道不适合 BDD。
我在这里写了一篇详细的博客post：Yes, Karate is not true BDD
请仔细阅读，并与将受益的人分享。是的，空手道从 Cucumber 窃取了 BDD syntax，但随后采取了不同的方向。
您可以通过 Java API. Or if you want to use something like REST-assured, full power to you.
在幕后使用空手道作为 Cucumber 步骤定义
我个人的意见是，请不要。你这样做会浪费时间：
- 确保“BA 友好”Gherkin 真正“通俗易懂的英语”并且处于正确的抽象级别（取决于您询问的对象）。准备 endless debates 关于您的 Cucumber 场景是否包含“特定于实现”的细节。
- 实际上是让你的 BA 编写小黄瓜，或者至少与开发团队合作编写它们。顺便说一句，正是这种 协作 是您从 BDD 中获得的最大价值 - 而不是 规范作为可执行测试的自动化。所以如果你真的能做到这一点（从你的文学士那里获得时间和小黄瓜专业知识），那么 - 恭喜！ Not many teams are able to pull this off.
- 当然小黄瓜只是tip of the iceberg, you need to go and write all the step-definitions. You would have seen this part of the Karate documentation that outlines the differences between Karate and Cucumber。
- 我有一个 strong 的观点，即 BDD 对于 API 测试的价值很小（也许是负面的）。 UI 测试（面向人类）与 API 测试（面向机器）之间的最大区别在于，API 测试具有明确的“合同”，您正在编码。最好用技术术语（JSON / 模式）而不是 BDD 强迫您进入的 故意 抽象来表达此契约。 API 的最终用户或消费者通常是 另一个程序员 ！是的，需要考虑 API as a product - 但 BDD 只是把事情做得太过火了。尤其是当涉及到微服务时，你很少会遇到比普通服务更复杂的事情 'CRUD'.
- 问问自己这个问题 - 您是否希望您的文学士在项目的需求定义阶段后继续阅读小黄瓜？请记住，应该在编写一行代码之前 实践 BDD 。如果 Gherkin 已实现其建立协作、共享理解和示例的目的 - 只需将其转换为正常的自动化测试，不要回头看！
编辑：查看 second example here 以了解当您使用 Cucumber 测试应该是简单单元或集成测试时会发生什么。
EDIT2（22 年 3 月 9 日）：2021 年，空手道发布不到 5 年，crossed Cucumber in terms of GitHub stars。我建议团队考虑放弃追求“纯 BDD”，转而评估空手道。
在使用 Karate 时，我们能够对 Web 服务进行大部分验证，我们能够成功地将 Karate 与 Selenium webdriver 集成，并使用 java 类 进行数据库断言。对于数据库，我们通过将每一行转换为哈希图将结果集返回为列表，而空手道将其作为 json 数组。所以验证变得简单。我们在 QA 方面的大部分需求都已使用 Karate 实现。
但是，今天我们向更大的社区介绍它时，其中一位开发负责人提出了一个问题。他是 JBehave、BDD、jsonpath、java、Web 服务等方面的专家。根据我们的上下文，我们也认为他的问题确实相关。但是，空手道的方法不同，据我们所知可能行不通。
在我们的上下文中，我们需要让 BA 使用业务术语考虑他们的业务场景来编写 BDD，QA/Dev 稍后可以将它们转换为脚本。 （我们通常使用黄瓜 + selenium/rest assured 等方法）。例如，如果我有一个特征文件和10个场景，业务方面的人将不会理解验证的细节看到的步骤在空手道/或换句话说，纯英语文本对他们来说会更容易理解。我们需要这种方法，因为我们试图从故事层面本身实施流程变更。
能否分享一下您的想法？
简短回答：空手道不适合 BDD。
我在这里写了一篇详细的博客post：Yes, Karate is not true BDD
请仔细阅读，并与将受益的人分享。是的，空手道从 Cucumber 窃取了 BDD syntax，但随后采取了不同的方向。
您可以通过 Java API. Or if you want to use something like REST-assured, full power to you.
在幕后使用空手道作为 Cucumber 步骤定义我个人的意见是，请不要。你这样做会浪费时间：
- 确保“BA 友好”Gherkin 真正“通俗易懂的英语”并且处于正确的抽象级别（取决于您询问的对象）。准备 endless debates 关于您的 Cucumber 场景是否包含“特定于实现”的细节。
- 实际上是让你的 BA 编写小黄瓜，或者至少与开发团队合作编写它们。顺便说一句，正是这种 协作 是您从 BDD 中获得的最大价值 - 而不是 规范作为可执行测试的自动化。所以如果你真的能做到这一点（从你的文学士那里获得时间和小黄瓜专业知识），那么 - 恭喜！ Not many teams are able to pull this off.
- 当然小黄瓜只是tip of the iceberg, you need to go and write all the step-definitions. You would have seen this part of the Karate documentation that outlines the differences between Karate and Cucumber。
- 我有一个 strong 的观点，即 BDD 对于 API 测试的价值很小（也许是负面的）。 UI 测试（面向人类）与 API 测试（面向机器）之间的最大区别在于，API 测试具有明确的“合同”，您正在编码。最好用技术术语（JSON / 模式）而不是 BDD 强迫您进入的 故意 抽象来表达此契约。 API 的最终用户或消费者通常是 另一个程序员 ！是的，需要考虑 API as a product - 但 BDD 只是把事情做得太过火了。尤其是当涉及到微服务时，你很少会遇到比普通服务更复杂的事情 'CRUD'.
- 问问自己这个问题 - 您是否希望您的文学士在项目的需求定义阶段后继续阅读小黄瓜？请记住，应该在编写一行代码之前 实践 BDD 。如果 Gherkin 已实现其建立协作、共享理解和示例的目的 - 只需将其转换为正常的自动化测试，不要回头看！
编辑：查看 second example here 以了解当您使用 Cucumber 测试应该是简单单元或集成测试时会发生什么。
EDIT2（22 年 3 月 9 日）：2021 年，空手道发布不到 5 年，crossed Cucumber in terms of GitHub stars。我建议团队考虑放弃追求“纯 BDD”，转而评估空手道。