Tags not being reported correctly

[ShoopIndy]

Unless I misunderstand intention of the tagging, the per-tag summary and individual tag reports are including scenarios for all tags.

Below is a simple example of this problem.

Given that I have a feature file containing 4 scenarios
And 2 scenarios are tagged with @tag1
And other 2 scenarios are tagged with @tag2
When I view the tag1 report
Then the tag1 report should have a total of 2 scenarios

However, the tag1 report has a total of 4 scenarios. The source json looks correct to me and I have validated it using http://cucumber-reporting.masterthought.net/. This problem happens with - net.masterthought.cucumber-reporting:0.0.21 - Ubuntu 12 and 13 - Ruby 1.9.3 and Ruby 2 - JDK 1.7 and openJDK6 and openJDK7 - chrome and firefox Please let me know if any other info would help troubleshoot this problem. This report looks correct to me:  However, this report shows each tag having 4 scenarios each when they only have 2 each:  ...and this report (just for tag1) shows it as having 4 scenarios when it only has 2. 

[kingsleyh]

oh looks like a bug - well spotted.

Do you happen to have backgrounds in there too? maybe the backgrounds are being counted

On 22 May 2013, at 17:18, ShoopIndy notifications@github.com wrote:

Unless I misunderstand intention of the tagging, the per-tag summary and individual tag reports are including scenarios for all tags.

Below is a simple example of this problem.

Given that I have a feature file containing 4 scenarios

And 2 scenarios are tagged with @tag1

And other 2 scenarios are tagged with @tag2

When I view the tag1 report

Then the tag1 report should have a total of 2 scenarios However, the tag1 report has a total of 4 scenarios.

The source json looks correct to me and I have validated it using http://cucumber-reporting.masterthought.net/.

This problem happens with

net.masterthought.cucumber-reporting:0.0.21 Ubuntu 12 and 13 Ruby 1.9.3 and Ruby 2 JDK 1.7 and openJDK6 and openJDK7 chrome and firefox Please let me know if any other info would help troubleshoot this problem.

This report looks correct to me:

However, this report shows each tag having 4 scenarios each when they only have 2 each:

...and this report (just for tag1) shows it as having 4 scenarios when it only has 2.

— Reply to this email directly or view it on GitHub.

[ShoopIndy]

@kingsleyh - no, there isn't a background in the feature file. Below is feature file in it's entirety.

p.s. Congrats! Hope all is going well with the new baby! (saw you mentioned this in another comment when I was researching this before)

Feature: cuke report test

  @tag1
  Scenario: scenario1 for tag1
    Then shoop expect pass

  @tag2
  Scenario: scenario1 for tag2
    Then shoop expect pass

  @tag1
  Scenario: scenario2 for tag1
    Then shoop expect fail

  @tag2
  Scenario: scenario2 for tag2
    Then shoop expect fail

[ShoopIndy]

@kingsleyh - Just a little more info to help you troubleshoot. (I'm anxious to use these reports!)

This same problem also occurs with 0.0.17, 0.0.20 versions of Cucumber-Reporting.

I'm starting to wonder whether this is really a problem further upstream (otherwise, this has been a bug since the beginning).

Here is the json that I used as example of the problem.

[
  {
    "keyword": "Feature",
    "name": "cuke report test",
    "line": 1,
    "description": "",
    "id": "cuke-report-test",
    "uri": "features/cukereport_test.feature",
    "elements": [
      {
        "keyword": "Scenario",
        "name": "scenario1 for tag1",
        "line": 4,
        "description": "",
        "tags": [
          {
            "name": "@tag1",
            "line": 3
          }
        ],
        "id": "cuke-report-test;scenario1-for-tag1",
        "type": "scenario",
        "steps": [
          {
            "keyword": "Then ",
            "name": "shoop expect pass",
            "line": 5,
            "match": {
              "arguments": [
                {
                  "offset": 13,
                  "val": "pass"
                }
              ],
              "location": "features/step_definitions/computeCPP_steps.rb:5"
            },
            "result": {
              "status": "passed",
              "duration": 679650
            }
          }
        ]
      },
      {
        "keyword": "Scenario",
        "name": "scenario1 for tag2",
        "line": 8,
        "description": "",
        "tags": [
          {
            "name": "@tag2",
            "line": 7
          }
        ],
        "id": "cuke-report-test;scenario1-for-tag2",
        "type": "scenario",
        "steps": [
          {
            "keyword": "Then ",
            "name": "shoop expect pass",
            "line": 9,
            "match": {
              "arguments": [
                {
                  "offset": 13,
                  "val": "pass"
                }
              ],
              "location": "features/step_definitions/computeCPP_steps.rb:5"
            },
            "result": {
              "status": "passed",
              "duration": 191278
            }
          }
        ]
      },
      {
        "keyword": "Scenario",
        "name": "scenario2 for tag1",
        "line": 12,
        "description": "",
        "tags": [
          {
            "name": "@tag1",
            "line": 11
          }
        ],
        "id": "cuke-report-test;scenario2-for-tag1",
        "type": "scenario",
        "steps": [
          {
            "keyword": "Then ",
            "name": "shoop expect fail",
            "line": 13,
            "match": {
              "arguments": [
                {
                  "offset": 13,
                  "val": "fail"
                }
              ],
              "location": "features/step_definitions/computeCPP_steps.rb:5"
            },
            "result": {
              "status": "failed",
              "error_message": "\nexpected: 2\n     got: 1\n\n(compared using ==)\n (RSpec::Expectations::ExpectationNotMetError)\n./features/step_definitions/computeCPP_steps.rb:9:in `/^shoop expect (.*)$/'\nfeatures/cukereport_test.feature:13:in `Then shoop expect fail'",
              "duration": 426627
            }
          }
        ]
      },
      {
        "keyword": "Scenario",
        "name": "scenario2 for tag2",
        "line": 16,
        "description": "",
        "tags": [
          {
            "name": "@tag2",
            "line": 15
          }
        ],
        "id": "cuke-report-test;scenario2-for-tag2",
        "type": "scenario",
        "steps": [
          {
            "keyword": "Then ",
            "name": "shoop expect fail",
            "line": 17,
            "match": {
              "arguments": [
                {
                  "offset": 13,
                  "val": "fail"
                }
              ],
              "location": "features/step_definitions/computeCPP_steps.rb:5"
            },
            "result": {
              "status": "failed",
              "error_message": "\nexpected: 2\n     got: 1\n\n(compared using ==)\n (RSpec::Expectations::ExpectationNotMetError)\n./features/step_definitions/computeCPP_steps.rb:9:in `/^shoop expect (.*)$/'\nfeatures/cukereport_test.feature:17:in `Then shoop expect fail'",
              "duration": 398624
            }
          }
        ]
      }
    ]
  }
]            

[kingsleyh]

Great thanks - I'm travelling at the moment but next week I should get time to investigate and fix the issues if they are fixable on the report side.

--k

Sent from my iPhone

On 23 May 2013, at 14:30, ShoopIndy notifications@github.com wrote:

@kingsleyh - Just a little more info to help you troubleshoot. (I'm anxious to use these reports!)

This same problem also occurs with 0.0.17, 0.0.20 versions of Cucumber-Reporting.

I'm starting to wonder whether this is really a problem further upstream (otherwise, this has been a bug since the beginning).

Here is the json that I used as example of the problem.

[ { "keyword": "Feature", "name": "cuke report test", "line": 1, "description": "", "id": "cuke-report-test", "uri": "features/cukereport_test.feature", "elements": [ { "keyword": "Scenario", "name": "scenario1 for tag1", "line": 4, "description": "", "tags": [ { "name": "@tag1", "line": 3 } ], "id": "cuke-report-test;scenario1-for-tag1", "type": "scenario", "steps": [ { "keyword": "Then ", "name": "shoop expect pass", "line": 5, "match": { "arguments": [ { "offset": 13, "val": "pass" } ], "location": "features/step_definitions/computeCPP_steps.rb:5" }, "result": { "status": "passed", "duration": 679650 } } ] }, { "keyword": "Scenario", "name": "scenario1 for tag2", "line": 8, "description": "", "tags": [ { "name": "@tag2", "line": 7 } ], "id": "cuke-report-test;scenario1-for-tag2", "type": "scenario", "steps": [ { "keyword": "Then ", "name": "shoop expect pass", "line": 9, "match": { "arguments": [ { "offset": 13, "val": "pass" } ], "location": "features/step_definitions/computeCPP_steps.rb:5" }, "result": { "status": "passed", "duration": 191278 } } ] }, { "keyword": "Scenario", "name": "scenario2 for tag1", "line": 12, "description": "", "tags": [ { "name": "@tag1", "line": 11 } ], "id": "cuke-report-test;scenario2-for-tag1", "type": "scenario", "steps": [ { "keyword": "Then ", "name": "shoop expect fail", "line": 13, "match": { "arguments": [ { "offset": 13, "val": "fail" } ], "location": "features/step_definitions/computeCPP_steps.rb:5" }, "result": { "status": "failed", "error_message": "\nexpected: 2\n got: 1\n\n(compared using ==)\n (RSpec::Expectations::ExpectationNotMetError)\n./features/step_definitions/computeCPP_steps.rb:9:in /^shoop expect (.*)$/'\nfeatures/cukereport_test.feature:13:inThen shoop expect fail'", "duration": 426627 } } ] }, { "keyword": "Scenario", "name": "scenario2 for tag2", "line": 16, "description": "", "tags": [ { "name": "@tag2", "line": 15 } ], "id": "cuke-report-test;scenario2-for-tag2", "type": "scenario", "steps": [ { "keyword": "Then ", "name": "shoop expect fail", "line": 17, "match": { "arguments": [ { "offset": 13, "val": "fail" } ], "location": "features/step_definitions/computeCPP_steps.rb:5" }, "result": { "status": "failed", "error_message": "\nexpected: 2\n got: 1\n\n(compared using ==)\n (RSpec::Expectations::ExpectationNotMetError)\n./features/step_definitions/computeCPP_steps.rb:9:in /^shoop expect (.*)$/'\nfeatures/cukereport_test.feature:17:inThen shoop expect fail'", "duration": 398624 } } ] } ] } ] — Reply to this email directly or view it on GitHub.

[walterg2]

Any update on this issue?

[kingsleyh]

hey - sorry not yet - but I'm getting to it - hopefully soon :) still dealing with nappies and no sleep!

On 26 Jun 2013, at 13:53, George T Walters II notifications@github.com wrote:

Any update on this issue?

— Reply to this email directly or view it on GitHub.

[walterg2]

HAH! I know how you feel. Have a six month old and he's decided that sleeping through the night isn't as much fun as he originally thought. I'll take a look and see what I can come up with on this. Hope to have something today or tomorrow for a Pull Request.

[kingsleyh]

That would be awesome thanks!!

On 26 Jun 2013, at 14:02, George T Walters II notifications@github.com wrote:

HAH! I know how you feel. Have a six month old and he's decided that sleeping through the night isn't as much fun as he originally thought. I'll take a look and see what I can come up with on this. Hope to have something today or tomorrow for a Pull Request.

— Reply to this email directly or view it on GitHub.

[msymons]

Is there an ETA on implementing this fix?

I think that this would address the huge mismatch that I see between the counts on the Feature Overview & the Tag Overview screens. Just an example, for me, the Tags Overview reports 6296 steps - compared with 2168 steps reported on the Features Overview screen.

This big mismatch is not even caused by heavy use of tagging... only 10% of my feature files use more than 1 tag. However, I want to use more. I am looking forward to a fix for the issue so that I can start to use just as many tags as I need and thus implement better traceability from my defect tracking system, etc. I then look forward to being able to push out the fix to other teams (as we have multiple Jenkins servers, etc).

[kingsleyh]

I can't give a definite eta but hopefully I will fix several defects over the weekend including this.

Sent from my iPad

On 4 Jul 2013, at 11:54, msymons notifications@github.com wrote:

Is there an ETA on implementing this fix?

I think that this would address the huge mismatch that I see between the counts on the Feature Overview & the Tag Overview screens. Just an example, for me, the Tags Overview reports 6296 steps - compared with 2168 steps reported on the Features Overview screen.

This big mismatch is not even caused by heavy use of tagging... only 10% of my feature files use more than 1 tag. However, I want to use more. I am looking forward to a fix for the issue so that I can start to use just as many tags as I need and thus implement better traceability from my defect tracking system, etc. I then look forward to being able to push out the fix to other teams (as we have multiple Jenkins servers, etc).

— Reply to this email directly or view it on GitHub.

[kingsleyh]

I have checked in a fix with the caveat that a scenario outline is only counted as 1 occurrence of a tag rather than the number of examples. I used the example json supplied to write some tests which now pass. But I'm not sure if it's enough to address all the problems.

The main defect was that all scenarios were being added to each tag list which caused the big mismatch in numbers - so it wasn't filtering only scenarios for tag1 into the scenario list for tag1.

Would anyone be willing to give the fix a try before I release it? If anyone wants to test the fix and give me feedback you can download the hpi file from here: http://www.masterthought.net/preview/cucumber-reports-22-snapshot-preview.hpi

Thanks :)

[walterg2]

I'll load this up on our CI box tonight and see what happens. Beat me to the solution.

I don't think only counting the Scenario Outline as a single run of the tag is an optimal solution as it deflates the numbers drastically the other way from what's out there now. The point of examples, as I understand (and use) them, is to allow the set up of a bunch of scenarios (like validating addresses, phone numbers and the like) and execute them multiple times without the need to copy and paste the same Gherkin over and over again. Excluding all of the examples from the counts will deflate the numbers to the point for some applications to the point of uselessness.

Either way, I'll run this tonight and share some results tomorrow morning. (My suite takes 2.5 hours to run).

[kingsleyh]

Great thanks :) I could probably work out a way to include scenario outline counts - but this fix hopefully is a step in the right direction at least.

--K

On 18 Jul 2013, at 00:49, George T Walters II notifications@github.com wrote:

I'll load this up on our CI box tonight and see what happens. Beat me to the solution.

I don't think only counting the Scenario Outline as a single run of the tag is an optimal solution as it deflates the numbers drastically the other way from what's out there now. The point of examples, as I understand (and use) them, is to allow the set up of a bunch of scenarios (like validating addresses, phone numbers and the like) and execute them multiple times without the need to copy and paste the same Gherkin over and over again. Excluding all of the examples from the counts will deflate the numbers to the point for some applications to the point of uselessness.

Either way, I'll run this tonight and share some results tomorrow morning. (My suite takes 2.5 hours to run).

— Reply to this email directly or view it on GitHub.

[walterg2]

Ran my suite last night and it's working as described above. As I expected, now we're under-reporting actual tests when running against tags. It's not too far off, but when you're running 10-12 tests to validate various address types within a Scenario Outline, it only looks like one.

Again, better than before, but possible enhancement update. I've attached a coulple of screen shots of the run before this snapshot and one after.

[msymons]

It seems that the changes so far will improve the "status" information quality as they should prevent a genuine fail that is reported for one tag from "infecting" the status of other tags that appear in the same feature file. Make sense?

I do agree with the comment that "Excluding all of the examples from the counts will deflate the numbers to the point for some applications to the point of uselessness" and hope that that area can be addressed. One thought... if the examples are being overlooked then will some tags be reported as passed when they actual fail (in examples) and vice versa?

[kingsleyh]

I'm going on holiday for 2 weeks - but when I get back I will do a re-write of the tags code to take into consideration scenario outlines as well. Yes you are right - if a scenario outline has a failing example it won't currently be included in the calculations - as only the scenarios that end up in the list for a given tag get included into the tag calculations. I will fix this area soon though.

I'm planning a general overhaul as well because there seems to be some deviance between the json created by the ruby version of cucumber and the cucumber-jvm version. So I would like to make sure both are handled correctly. Please let me know if you have any other request to consider for the overhaul.

--K

On 19 Jul 2013, at 18:53, msymons notifications@github.com wrote:

It seems that the changes so far will improve the "status" information quality as they should prevent a genuine fail that is reported for one tag from "infecting" the status of other tags that appear in the same feature file. Make sense?

I do agree with the comment that "Excluding all of the examples from the counts will deflate the numbers to the point for some applications to the point of uselessness" and hope that that area can be addressed. One thought... if the examples are being overlooked then will some tags be reported as passed when they actual fail (in examples) and vice versa?

— Reply to this email directly or view it on GitHub.

[msymons]

How's it going with the tags code refactoring?

Can I double-check one thing. Would I be correct in assuming that the URLs for the tag reports would be unchanged after the overhaul? I'm guessing that nothing will change but want to be sure.

I link from various systems (such as issue tracking and requirement management) to the cucumber reports and want to add in a lot more links to the tag reports, in preparation for the day that all the stats in the reports are correct. I would not want to have to go back and edit all the links later.

[kingsleyh]

Hi

It's going slowly - but this weekend I hope to have a long refactoring session.

None of the urls will change.

As a side note I've just written cucumber-sandwich which is a standalone app that monitors the cucumber json and generates a new report on change. Where I'm working has no maven so it's quite useful when running locally. Ill be pushing it to git over the weekend

--k

Sent from my iPhone

On 30 Aug 2013, at 12:41, msymons notifications@github.com wrote:

How's it going with the tags code refactoring?

Can I double-check one thing. Would I be correct in assuming that the URLs for the tag reports would be unchanged after the overhaul? I'm guessing that nothing will change but want to be sure.

I link from various systems (such as issue tracking and requirement management) to the cucumber reports and want to add in a lot more links to the tag reports, in preparation for the day that all the stats in the reports are correct. I would not want to have to go back and edit all the links later.

— Reply to this email directly or view it on GitHub.

[imakowski]

Do you know when new release with this fix will be available?

[montells]

Thanks for this useful plugin. But I'll really preciate the fix for this issue. Can I know when it will be fixed.

The problem is not in outline scenaries, this is more closed to multiple-taggin issue.

[kingsleyh]

Hey

I'm hoping to release soon - I've been adjusting to parenthood :)

Sent from my iPad

On 2 Oct 2013, at 20:31, Michel Sánchez Montells notifications@github.com wrote:

Thanks for this useful plugin. But I'll really preciate the fix for this issue. Can I know when it will be fixed.

The problem is not in outline scenaries, this is more closed to multiple-taggin issue.

— Reply to this email directly or view it on GitHub.

[msymons]

I'm looking forward to what you come up with, once the diaper/nappy load decreases a bit and you get some time to code. I am not a developer myself, & so cannot contribute my own code. But I am a tester, and will happily spend time correlating tag vs scenario counts, etc, and provide feedback.

[tombarber]

Hey

Do you know roughly when this fix is likely to be released yet? Will be really useful.

Many thanks

[kingsleyh]

Hi

I'm looking at it soon - so hopefully after Christmas I'll make a new release with a lot of fixes.

Sent from my iPhone

On 19 Dec 2013, at 09:50, Tom Barber notifications@github.com wrote:

Hey

Do you know roughly when this fix is likely to be released yet? Will be really useful.

Many thanks

— Reply to this email directly or view it on GitHub.

[amit-taware]

Hey

Do you know roughly when this fix is likely to be released?

Many thanks Amit

[amit-taware]

Can u please release the version of fixes on maven repo? Do you know roughly when this fix is likely to be released?

Or if u have code or Jars of Beta version can u please share it. I would love to test it Many thanks Amit

[imakowski]

Did you fix this in latest release?

[kingsleyh]

The tags issue is still not fixed. I tried a few different ideas but that led to under reporting which was not very useful. At least I managed to merge everyones pull requests and make a release.

I'll revisit the tags issue soon though. It would be very helpful if someone could make me a test json which covers the different scenarios and expectations the tag functionality should cope with as well as an explanation of what is expected.

This would speed up the delivery considerably because coming up with the test cases is the most time consuming thing.

--K

On 3 Mar 2014, at 11:51, imakowski notifications@github.com wrote:

Did you fix this in latest release?

— Reply to this email directly or view it on GitHub.

[ghost]

Hey,

Do you have any update on the issue?

PFA the tag report overview that gets generated.

PFB the json code that gets generated:

[ { "id": "view-reports-submitted-by-clients", "description": "", "name": "View Reports submitted by Clients", "keyword": "Feature", "line": 1, "elements": [ { "after": [ { "result": { "duration": 421416607, "status": "passed" }, "match": { "location": "reports_Submitted_By_Clients.tearDown()" } } ], "id": "view-reports-submitted-by-clients;officer-can-view-ers-reports-on-console;;2", "tags": [ { "name": "@View_Report", "line": 3 } ], "before": [ { "result": { "duration": 6166754112, "status": "passed" }, "match": { "location": "reports_Submitted_By_Clients.setup(Scenario)" } } ], "description": "", "name": "Officer_Can_View_ERS_Reports_On_Console", "keyword": "Scenario Outline", "line": 12, "steps": [ { "result": { "duration": 2966412953, "status": "passed" }, "name": "The officer has logged into the ERS Management console", "keyword": "Given ", "line": 5, "match": { "location": "reports_Submitted_By_Clients.loginIntoERS()" } }, { "result": { "duration": 5442853741, "status": "passed" }, "name": "The officer \"Acosta, Mike\" selects a client \"Clyburn, Earl\"", "keyword": "When ", "line": 6, "match": { "arguments": [ { "val": "Acosta, Mike", "offset": 13 }, { "val": "Clyburn, Earl", "offset": 45 } ], "location": "reports_Submitted_By_Clients.officerSelectsClient(String,String)" }, "matchedColumns": [ 0, 1 ] }, { "result": { "duration": 534167960, "status": "passed" }, "name": "Clicks on report 2", "keyword": "And ", "line": 7, "match": { "arguments": [ { "val": "2", "offset": 17 } ], "location": "reports_Submitted_By_Clients.selectReport(int)" }, "matchedColumns": [ 2 ] }, { "result": { "duration": 975309752, "status": "passed" }, "name": "The bottom half of the screen should display the basic information", "keyword": "Then ", "line": 8, "match": { "location": "reports_Submitted_By_Clients.verifySummaryReportFields()" } } ], "type": "scenario" }, { "after": [ { "result": { "duration": 355735235, "status": "passed" }, "match": { "location": "reports_Submitted_By_Clients.tearDown()" } } ], "id": "view-reports-submitted-by-clients;officer-can-view-different-clients-reports;;2", "tags": [ { "name": "@View_Another_Officer_Client_Report", "line": 14 } ], "before": [ { "result": { "duration": 4980431641, "status": "passed" }, "match": { "location": "reports_Submitted_By_Clients.setup(Scenario)" } } ], "description": "", "name": "Officer_Can_View_Different_Clients_Reports", "keyword": "Scenario Outline", "line": 22, "steps": [ { "result": { "duration": 2482864087, "status": "passed" }, "name": "The officer has logged into the ERS Management console", "keyword": "Given ", "line": 16, "match": { "location": "reports_Submitted_By_Clients.loginIntoERS()" } }, { "result": { "duration": 4957179102, "status": "passed" }, "name": "The officer \"Acosta, Mike\" selects a client \"Ingram, Larry\"", "keyword": "When ", "line": 17, "match": { "arguments": [ { "val": "Acosta, Mike", "offset": 13 }, { "val": "Ingram, Larry", "offset": 45 } ], "location": "reports_Submitted_By_Clients.officerSelectsClient(String,String)" }, "matchedColumns": [ 0, 1 ] }, { "result": { "duration": 585502624, "status": "passed" }, "name": "A list of reports should be displayed", "keyword": "Then ", "line": 18, "match": { "location": "reports_Submitted_By_Clients.displayReportCount()" } } ], "type": "scenario" }, { "after": [ { "result": { "duration": 346389306, "status": "passed" }, "match": { "location": "reports_Submitted_By_Clients.tearDown()" } } ], "id": "view-reports-submitted-by-clients;officer-can-view-different-clients-reports;;3", "tags": [ { "name": "@View_Another_Officer_Client_Report", "line": 14 } ], "before": [ { "result": { "duration": 4419922244, "status": "passed" }, "match": { "location": "reports_Submitted_By_Clients.setup(Scenario)" } } ], "description": "", "name": "Officer_Can_View_Different_Clients_Reports", "keyword": "Scenario Outline", "line": 23, "steps": [ { "result": { "duration": 2363842567, "status": "passed" }, "name": "The officer has logged into the ERS Management console", "keyword": "Given ", "line": 16, "match": { "location": "reports_Submitted_By_Clients.loginIntoERS()" } }, { "result": { "duration": 6380753093, "status": "passed" }, "name": "The officer \"Frisby, Suzette\" selects a client \"Brown, Sonya\"", "keyword": "When ", "line": 17, "match": { "arguments": [ { "val": "Frisby, Suzette", "offset": 13 }, { "val": "Brown, Sonya", "offset": 48 } ], "location": "reports_Submitted_By_Clients.officerSelectsClient(String,String)" }, "matchedColumns": [ 0, 1 ] }, { "result": { "duration": 496225502, "status": "passed" }, "name": "A list of reports should be displayed", "keyword": "Then ", "line": 18, "match": { "location": "reports_Submitted_By_Clients.displayReportCount()" } } ], "type": "scenario" } ], "uri": "src/FeatureFile/reports_Submitted_By_Clients.feature" } ]

Kindly let me know if you need more info.

Thanks, Arjun

[damianszczepanik]

First problem is already fixed, second example will be fixed with next release. The problem happened when two scenarios have the same name