[karate-gatling] explore ways of composing existing tests better for specific flows

Triggered by this question on Stack Overflow: https://stackoverflow.com/q/51504264/143475 and others who have discussed this with me as well.

Please comment and add asks / opinion.

I see the following themes:

• when there already exists a bunch of Karate tests, it should be possible to “pick and choose” some of them, treat as a unit and then use that unit in a Gatling simulation.
• I think the above is best solved by tags. so you can declare that only some tags should participate in a Gatling run
• ideally your existing features should be split into fine-grained flows.
• but I get that people want to have feature files with multiple scenarios
• proposal: a tag of the form @name=foo will be considered special in Karate
• this is how you can control WHICH scenarios to isolate in a given feature. for e.g. in Gatling scenarioNames( "createUser,deleteUser")
• if we have a Karate-native means of calling a feature BUT only invoke a certain Scenario then for Gatling all you need to do is write one extra “wrapper” feature, which would be “thin” that can “delegate” to or “orchestrate” all the other features and scenarios that need to be called. this needs more thinking and will evolve I am guessing. it might be better to have this “orchestration” definable in Gatling itself to avoid one extra layer

[ptrthomas]

additional thought, should be possible to refer to the feature+scenario directly in one short-cut notation:

karateFeature("classpath:mock/cats-create.feature@name=foo")

would we need any other meta info on top of this ?

[ptrthomas]

@manoj404 a couple of extra points. just so that I can explain this to others later:

• remember that this is a perf test. gatling will run each unit in parallel. there’s no way you can inter-depend
• if you already have a CRUD test for say DELETE, you will naturally have a CREATE as a “pre-requisite” for that flow. isn’t this how most teams do testing. if you are really smart about tests you may modularize so that you have a re-usable C flow - but still you will have a single feature that will run C first and then D

hope that makes sense !