在Karate中，我们如何与BA合作以实现业务场景的自动化

Question

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

然而，今天我们介绍的时候，对于一个更大的社区，其中一个开发者提出了一个问题。他是JBehave，BDD，jsonpath，java，Web服务等方面的专家。我们也认为他的问题在我们的背景下非常相关。然而，空手道的方法是不同的，它可能根据我们的知识不起作用。

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

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

Answer 1

简短回答：空手道不适合BDD。

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

请仔细阅读，并与将受益的人分享。是的，空手道从黄瓜手中偷走了BDD 语法，但后来采取了不同的方向。

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

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

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

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

希望有所帮助：）