使用Karate时,我们能够进行大多数Web服务验证,我们能够成功地将Karate与Selenium webdriver集成在一起,并使用java类进行DB断言。对于数据库,我们通过将每一行转换为哈希图来将结果集作为列表返回,而空手道将其作为json数组。因此验证变得简单。使用空手道可以满足我们在质量检查方面的大多数需求。

但是,今天当我们介绍它时,它的开发负责人之一提出了一个更大的社区。他是JBehave,BDD,jsonpath,java,Web服务等方面的专家。根据我们的上下文,我们还认为他的问题确实很重要。但是,根据我们的知识,空手道的方法不同,可能无法奏效。

在我们的上下文中,我们需要让BA使用业务术语考虑其业务场景来编写BDD,然后QA / Dev可以将其转换为脚本。 (我们通常采用黄瓜+硒/放心的方法等)。例如,如果我有一个功能文件和10个场景,那么业务方面的人将不了解验证的详细信息,看到空手道中的步骤,或者换句话说纯英文文本对于他们来说将更加不言自明。我们需要这种方法,因为我们尝试从故事级别本身实施流程更改。

您能分享您的想法吗?

最佳答案

简短答案:空手道不适合BDD。

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

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

您可以通过Java API在后台使用空手道作为黄瓜步进定义。或者,如果您想使用类似REST-assured, full power to you的名称。

我个人的看法是,请不要。您会浪费时间这样做:


确保“ BA友好型”小黄瓜确实是“普通英语”,并且处于正确的抽象级别(取决于您要求的人)。为endless debates准备有关您的黄瓜方案是否包含“特定于实现”的详细信息。
实际上是让您的BA编写Gherkin或至少与开发团队合作编写它们。顺便说一下,正是这种协作才是您从BDD获得的最大价值,而不是规范作为可执行测试的自动化。因此,如果您真的可以做到这一点(从您的文学士那里获得时间和小黄瓜专业知识),那么恭喜您! Not many teams are able to pull this off
当然,小黄瓜只是冰山一角,您需要去write all the step-definitions。您会在空手道文档的这部分中看到,概述了differences between Karate and Cucumber
我强烈认为BDD对API测试的价值很小(甚至可能是负数)。 UI测试(面向人类)与API测试(面向机器)之间的最大区别在于,您要编写明确的“合同”。最好用技术术语(JSON /模式)来表达此合同,而不是用BDD强迫您故意使用的抽象。 API的最终用户或使用者通常是另一个程序员!是的,有必要考虑API as a product-但是BDD的作用太远了。特别是在微服务方面,您很少会遇到比普通“ CRUD”做的事情更复杂的事情。
问问自己这个问题-您是否希望您的BA-s在项目的需求定义阶段之后继续阅读Gherkin?请记住,应该在编写一行代码之前先实践BDD。如果Gherkin实现了建立协作,共享理解和示例的目的-只需将其转换为常规的自动化测试即可,不要回头!


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

希望有帮助:)

09-10 20:36