A pattern that I have found super useful is to keep the scenarios in the feature files business specific/relevant. Then, in the step definitions do all the technical things like the specific REST calls and assertions.
When I first saw Karate I thought wow - this is just what I am looking for. A way for testers to use cucumber but be able to write the step definitions without needing to write java code. Then, I was sad when I saw that "Single Layer of Code To Maintain" was being marketed as the feature and the technical API things which the business wouldn't care about are being pushed write up to the feature definition.
My questions is... Is there a way (or consideration on the roadmap) to be able to define standard cucumber scenarios that map down (via the typical regex paradigm) to step definitions written using Karate?
Below is an example of roughly what I am trying to achieve... It might not even be a particularly great example but I needed something to paint a picture and get people thinking in similar terms.
Scenario: Search for skills
Given "Bob" has "Karate" as a skill
And "BDD" is an available skill
And "Bob" does not have "BDD" as a skill
When Jane searches "Bob"'s skills
Then she will see "Karate"
And not "BDD"
Then I want to have step definitions from the BDD scenario.
^Given (.) has (.) as a skill$
Given url 'http://myhost.com/candidates'
And request '{ name: "${1}". skills: ["${2}"] }'
When method post
Then status 201
And response == { id: '#notnull', name: '${1}', skills: ["${2}"] }
^And (.*) is an available skill$
Given url 'http://myhost.com/skills'
And request '{ skills: ["${1}"] }'
When method post
Then status 201
And response == { skills: ["${1}"] }
^And (.) does not have (.) as a skill$
Given url 'http://myhost.com/candidates/${1}'
And request '{ name: "${1}", skills: ["${2}"] }'
When method get
Then status 200
And response == (TODO: assert ${2} is not in skills list... sorry didn't have time to find the valid karate syntax)
^When .* searches (.*)'s skills$
Given url 'http://myhost.com/candidates/${1}'
When method get
^Then .* will see (.*)$
Then response == { id: '#notnull', name: '#notnull', skills: ["${1}"] }
^And not (.*)$
Then response == (TODO: check that it doesn't have ${1} as skill)
I realise there is some complexity in my example. For instance, the first 3 step definitions have fully contained G/W/T. Where as the last 3 steps definitions is on G/W/T split across 3 step definitions.
I am not necessarily needing something exactly like my example but using it as a way to try to tease out if there is any patterns I can use of combining the Scenarios with Cucumber JVM regex that map down to the Karate DSL.
Thanks in advance
