karate - 在 Karate 中，我们如何与 BA 协作来自动化业务场景

Question

在使用 Karate 时，我们能够对 Web 服务进行大部分验证，我们能够成功地将 Karate 与 Selenium Webdriver 集成，并使用 java 类进行数据库断言。对于 DB，我们通过将每一行转换为 HashMap 来将结果集作为列表返回，而 Karate 将其作为 json 数组。因此验证变得简单。我们在 QA 方面的大部分需求都已通过 Karate 实现了。

然而，今天当我们向更大的社区介绍时，一位开发负责人提出了一个问题。他是 JBehave、BDD、jsonpath、java、Web 服务等方面的专家。根据我们的上下文，我们还认为他的问题确实相关。然而， Karate 的方法不同，根据我们的了解，它可能行不通。

在我们的上下文中，我们需要让 BA 使用业务术语考虑其业务场景来编写 BDD，并且 QA/Dev 可以稍后将它们转换为脚本。 (我们通常遵循使用 cucumber + Selenium /放心等的方法)。例如，如果我有一个功能文件和10个场景，业务人员将无法理解 Karate/或其他内容中的步骤的验证细节。对于他们来说，简单的英文文本将更加不言自明。我们需要这种方法，因为我们尝试从故事级别本身实现流程更改。

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

Answer 1

简短回答: Karate 不适合 BDD。

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

请仔细阅读，并分享给那些受益的人。是的， Karate 从 Cucumber 窃取了 BDD 语法，但随后采取了不同的方向。

您可以通过 Java API 在幕后使用 Karate 作为 Cucumber 步骤定义。 。或者，如果您想使用类似 REST-assured, full power to you 的内容.

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

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

编辑:看看 second example here看看当您使用 Cucumber 测试本应是简单的单元或集成测试时会发生什么。

EDIT2(22 年 3 月 9 日):2021 年， Karate 发布不到 5 年，它 crossed Cucumber in terms of GitHub stars 。我建议团队考虑放弃对“纯粹BDD”的追求，转而评估 Karate 。

编辑3:2023年，SmartBear laid-off the co-founder of Cucumber - “最后剩下的员工 [...] 全职从事开源项目”。