In Karate how we can collaboratively work along with BA to automate business scenarios
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.
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.
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?
Answer
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 :)