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

While using Karate we were able to do most of the validations for web services, we were able to successfully integrate Karate with Selenium webdriver and do DB assertions using java classes. For DB we returned the results sets as list by converting each row as a hashmap and Karate took it as json array. So the validations became simple. Most of the needs for us on a QA side have been achieved using Karate.

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

However, today when we introduced, it to a bigger community one of the dev lead came up with a question. He is an expert in JBehave, BDD, jsonpath, java, web services etc. We also felt his question is really relevant based on our context. however, the approach of Karate is different and it may not work according to our knowledge.

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

In our context, we need to make the BA write the BDD considering their business scenarios using business terms and QA/Dev can later convert these as scripts. (An approach which we usually follow using cucumber + selenium/rest assured etc). For example, if I have a feature file and 10 scenarios in that, people on the business side will not understand the details of validations seeing the steps in karate/ or in another word plain English text will be little more self-explanatory for them. We need this approach because we try to implement process changes from story level itself.

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

Could you please share your thoughts?

推荐答案

简答:空手道不适合 BDD.

Short answer: Karate is not for BDD.

我在这里写了一篇关于它的详细博客文章:是的，空手道不是真 BDD

I wrote a detailed blog post about it here: Yes, Karate is not true BDD

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

Do read it carefully, and share it with those who will benefit. Yes, Karate steals the BDD syntax from Cucumber, but then takes a different direction.

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

You may be able to use Karate behind the scenes as Cucumber step-definitions via the Java API. Or if you want to use something like REST-assured, full power to you.

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

My personal opinion is, please don't. You will be wasting time doing this:

确保BA 友好"Gherkin 真正是简单的英语"；并且处于正确的抽象级别(取决于你问的是谁).为无尽 争论 你的 Cucumber 场景是否包含特定于实现"细节与否.实际上让您的 BA 编写 Gherkin，或者至少与开发团队合作编写它们.顺便说一句，正是这种协作是您从 BDD 获得的最大价值 - 而不是将规范作为可执行测试的自动化.所以如果你真的能做到这一点(从你的 BA 那里获得时间和 Gherkin 专业知识)，那么恭喜你！没有多少团队能够做到这一点.当然小黄瓜只是冰山一角，你需要去写下所有的步骤定义.您会看到空手道文档的这一部分，其中概述了 空手道和 Cucumber 之间的区别.我有一个强烈的观点，即 BDD 对 API 测试的价值很小(而且可能是负面的).UI 测试(面向人类)与 API 测试(面向机器)之间的最大区别在于 API 测试具有明确的契约".你正在编码的.这个契约最好用技术术语(JSON/模式)来表达，而不是 BDD 强制你进入的 deliberate 抽象.API 的最终用户或消费者通常是另一个程序员！是的，有必要将 API 视为产品 - 但 BDD 做得太过分了.尤其是在微服务方面，您很少会遇到比普通CRUD"更复杂的事情.问自己这个问题 - 您是否希望您的 BA 在项目的需求定义阶段之后继续阅读 Gherkin?请记住，BDD 应该在编写一行代码之前进行.如果 Gherkin 实现了建立协作、共同理解和示例的目的 - 只需将其转换为正常的自动化测试，不要回头！ Ensuring that the "BA friendly" Gherkin is truly "plain English" and is at the right level of abstraction (depending on who you ask). Be prepared for endless debates as to whether your Cucumber scenarios are containing "implementation specific" detail or not. Actually getting your BA-s to write the Gherkin or at least collaborate with the dev team to write them. By the way, it is this collaboration that is the greatest value you get from BDD - not the automation of the spec as executable tests. So if you can actually do this (getting time and Gherkin expertise from your BA-s), well - congratulations ! Not many teams are able to pull this off. Of course Gherkin is just the 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. I have a strong point of view that BDD has very little (and perhaps negative) value for API tests. The big difference between a UI test (human facing) vs an API test (machine facing) is that an API test has a clear "contract" that you are coding to. This contract is best expressed in technical terms (JSON / schema) instead of the deliberate abstraction that BDD forces you into. The end-user or consumer of an API is typically another programmer ! Yes, there is a need to think of the API as a product - but BDD is just taking things too far. And especially when it comes to micro-services, you will rarely encounter one that is doing something more complex than plain 'CRUD'. Ask yourself this question - are you expecting your BA-s to continue to read the Gherkin after the requirements definition phase of the project ? Keep in mind BDD is supposed to be practiced before a single line of code is written. If the Gherkin has fulfilled its purpose of establishing collaboration, a shared understanding, and examples - just convert it to normal automated tests and don't look back !

查看 这里的第二个示例，看看是什么当您使用 Cucumber 测试应该是简单的单元或集成测试时会发生这种情况.

Look at the second example here to see what happens when you use Cucumber to test what should been a simple unit or integration test.

希望有帮助:)