在空手道中，我们如何与 BA 协作以自动化业务场景

Question

在使用空手道时，我们能够对 Web 服务进行大部分验证，我们能够成功地将空手道与 Selenium webdriver 集成，并使用 java 类进行 DB 断言。对于 DB，我们通过将每一行转换为哈希图将结果集作为列表返回，空手道将其作为 json 数组。所以验证变得简单。我们在 QA 方面的大部分需求都是使用空手道实现的。

但是，今天当我们向更大的社区介绍它时，其中一位开发负责人提出了一个问题。他是 JBehave、BDD、jsonpath、java、Web 服务等方面的专家。根据我们的上下文，我们也觉得他的问题非常相关。但是，空手道的方法不同，据我们所知，它可能行不通。

在我们的上下文中，我们需要让 BA 使用业务术语考虑他们的业务场景来编写 BDD，然后 QA/Dev 可以稍后将这些转换为脚本。 （我们通常使用黄瓜+硒/放心等的方法）。例如，如果我有 一个功能文件 和 10 个场景，业务方面的人将无法理解验证的细节，看到 karate/ 或其他中的步骤word 纯英文文本对他们来说会更不言自明。我们需要这种方法，因为我们尝试从故事级别本身实施流程更改。

你能分享一下你的想法吗？

Answer 1

简答：空手道不适合 BDD。

我在这里写了一篇详细的博文：Yes, Karate is not true BDD

请仔细阅读，并与受益者分享。是的，空手道从 Cucumber 那里窃取了 BDD 语法，但随后采取了不同的方向。

您可以通过Java API 在幕后使用空手道作为 Cucumber 步骤定义。或者，如果您想使用 REST-assured, full power to you 之类的东西。

我的个人意见是，请不要。你这样做会浪费时间：

• 确保“对 BA 友好”的 Gherkin真正是“简单的英语”并且处于正确的抽象级别（取决于您询问的对象）。准备好endlessdebates 你的 Cucumber 场景是否包含“特定于实施”的细节。
• 实际上让您的 BA 编写 Gherkin 或至少与开发团队合作编写它们。顺便说一句，正是这种协作是您从 BDD 获得的最大价值 - 而不是将规范作为可执行测试的自动化。所以，如果你真的能做到这一点（从你的 BA 那里获得时间和 Gherkin 专业知识），那么恭喜你！ Not many teams are able to pull this off。
• 当然小黄瓜只是冰山一角，你需要去write all the step-definitions。您会看到空手道文档的这一部分，其中概述了differences between Karate and Cucumber。
• 我有一个强烈的观点，即 BDD 对 API 测试的价值很小（可能是负面的）。 UI 测试（面向人类）与 API 测试（面向机器）之间的最大区别在于，API 测试有一个明确的“合同”，您正在编写代码。这个契约最好用技术术语（JSON / 模式）来表达，而不是 BDD 强制你进入的 deliberate 抽象。 API 的最终用户或消费者通常是另一个程序员！是的，有必要考虑API as a product - 但BDD 只是把事情做得太过分了。尤其是在微服务方面，您很少会遇到比简单的“CRUD”更复杂的事情。
• 问自己这个问题 - 您是否希望您的 BA 在项目的需求定义阶段之后继续阅读 Gherkin？请记住，BDD 应该在编写一行代码之前进行。如果 Gherkin 实现了建立协作、共同理解和示例的目的 - 只需将其转换为正常的自动化测试，不要回头！

编辑：查看second example here 以了解当您使用 Cucumber 测试应该是简单的单元或集成测试时会发生什么。

EDIT2（22 年 3 月 9 日）：2021 年，距离空手道发布不到 5 年，crossed Cucumber in terms of GitHub stars。我建议团队考虑放弃追求“纯 BDD”，转而评估空手道。