问题描述
使用Karate时，我们可以对Web服务进行大多数验证，但我们可以成功地将Karate与Selenium webdriver集成在一起，并使用java类进行数据库声明.对于DB，我们通过将每一行转换为哈希图来将结果集作为列表返回，而空手道将其作为json数组.因此，验证变得简单.使用空手道已经满足了我们在质量检查方面的大多数需求.
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个场景，那么在业务方面，人们将不会看到空手道/或其他步骤中的步骤，从而无法了解验证的详细信息.普通英语单词一词对他们来说将更加不言自明.我们需要这种方法，因为我们尝试从故事级别本身实施流程更改.
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.
您能分享您的想法吗?
推荐答案
简短答案:空手道不适用于BDD.
Short answer: Karate is not for BDD.
我在此处撰写了详细的博客文章:是的，空手道不是 true 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在后台使用空手道作为黄瓜的逐步定义. .或者，如果您想使用类似 REST保证的功能，给您.
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友好型"小黄瓜是真正普通英语"，并且处于正确的抽象级别(取决于您询问的人).为无止境关于您的黄瓜方案是否包含特定于实现的"详细信息或辩论不是.
- 实际上是让您的BA-s编写Gherkin，或者至少与开发团队合作编写它们.顺便说一下，正是这种协作是您从BDD获得的最大价值-不是规范作为可执行测试的自动化.因此，如果您真的可以做到这一点(从您的文学士那里获得时间和小黄瓜专业知识)，那么恭喜您！ 没有多少团队能够做到这一点.
- 当然，小黄瓜只是冰山一角，您需要去编写所有步骤定义.您会看到空手道文档的这一部分，其中概述了空手道与黄瓜之间的区别.
- 我有一个 strong 观点，认为BDD对API测试的价值很小(甚至可能是负数). UI测试(面向人类)与API测试(面向机器)之间的最大区别在于，您要编写明确的合同".该合同最好用技术术语(JSON/架构)表示，而不是BDD强迫您使用的故意抽象. API的最终用户或使用者通常是另一个程序员！是的，有必要将 API视为产品-但是BDD只是把事情推得太远了.特别是在微服务方面，您很少会遇到比普通"CRUD"做的事情还要复杂的事情.
- 问自己一个问题-您是否希望BA-s在项目的需求定义阶段之后继续阅读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 there is 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.
希望有帮助:)
这篇关于在空手道中，我们如何与BA协同工作以自动化业务场景的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！