In Karate how we can collaboratively work along with BA to automate business scenarios

a 夏天 提交于 2019-11-26 19:09:24

Short answer: Karate is not for BDD.

I wrote a detailed blog post about it here: Yes, Karate is not true 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.

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:

  • 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 !

EDIT: 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.

Hope that helps :)

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!