JSON report - Feature name & description values differs from cucumber

[grasshopper7]

The feature name field displays the relative path, whereas the cucumber report value is the feature name, if available. The feature description field displays the combination of name and description, whereas cucumber one only has the description, if available.

Changes I made in the toCucumberJson() method of FeatureResult class.

map.put("name", feature.getName() == null ? "" : feature.getName());
map.put("description", feature.getDescription() == null ? "" : feature.getDescription());

Can these field values be changed to match that of cucumber or is there a logic I am missing? Though there could be code implications for existing third party reports which are using the current values. Thanks.

[ptrthomas]

@grasshopper7 this I'm not in favor of. please see: https://stackoverflow.com/a/56492225/143475

[grasshopper7]

Cluecumber suffers from the same 'fate' of path as feature name, which I am trying to avoid. Will parse the description field which contains the name, else fall back to the default value.
Thanks for the links, quite informative.

[ptrthomas]

@grasshopper7 thanks. I'm open to adding a configuration option to switch behavior, but would really like to be more convinced. so far only 2 or 3 people including you have brought this up. you are welcome to submit a PR

[grasshopper7]

@ptrthomas It is just been only a week since I have used Karate in any shape or form, and that too restricted to api testing. So I am not sure about the logic or thinking behind most things. But anyways, below is how I look at this.

First, I believe the value of the feature name is hidden in the report. If an user enters a valid name then that should be available. Similarly the description field is modified which does not reflect the actual value. If the thinking is too avoid errors due to missing feature name then the relative path can be used as default.

Second, as this is identical to the cucumber json report, expectation would be that the same logic in terms of fields and values are available. Else the cucumber json dependent reporting solution will need to take care of the differences. Though I feel that retro-fitting Cucumber reports for Karate (for api testing) does not portray a clear picture.

Let me know if this seems logical. Would be open to creating a PR if you decide to proceed on this.
Thanks.

BTW - Something off topic - Does Karate support a slack channel or some forum where questions can be asked. Stackoverflow zealously closes queries not backed by code samples.

[ptrthomas]

@grasshopper7 I'm ok to accept a PR but current behavior will be the default. but if it turns out to be overly complex we may reconsider. for now you can ask questions here.

I'm not worried about compatibility with how cucumber is supposed to work to be honest, we can try though: https://twitter.com/ptrthomas/status/1424259563503587330

[ptrthomas]

@grasshopper7 had a quick look. considering what I said already, I certainly don't want to pollute the karate API with these cucumber things we don't care about. I would move this to a karate.configure() setting. for an example, see what we did for this case: #755 - so the impact on code and API is less.

for example how do CLI users switch this on or off ? it needs thinking about, and the configure option is an easy way out. https://github.com/karatelabs/karate/tree/develop/karate-netty#usage

we will also require updates to documentation before we accept a PR.