Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eclipse JUnit reports inaccurate run count #263

Closed
dgradl opened this issue Mar 19, 2012 · 22 comments
Closed

Eclipse JUnit reports inaccurate run count #263

dgradl opened this issue Mar 19, 2012 · 22 comments

Comments

@dgradl
Copy link
Contributor

dgradl commented Mar 19, 2012

Using the eclipse JUnit feature cucumber junit is over-reporting the run count by seemingly double. For example with 4 scenarios of 3 steps (with steps not written yet) each it reports Runs: 24/12. In terms of the double counting it seems to be a matter of the way in which JUnitReporter is sending notifier events to the EachStepNotifier. It doesn't seem to be consistent with JUnit itself, where if a test is ignored, it does a fireTestIgnored without a fireTestStarted.

I also question whether each individual cucumber step (GIVEN, WHEN, THEN) should be counted as a run as opposed to just the scenario or example itself. I generally expect the run count to give me a number of tests invoked (in JUnit it is a reflection of number of @tests). However, its really only a count of steps. After writing several scenarios with multiple GIVEN-AND and THEN-ANDs on a project I am working on it reported 390 runs, but its really only 90 some tests executed.

@aslakhellesoy
Copy link
Contributor

What cucumber-jvm version are you running?

Cucumber features are reported in a JUnit hierarchy:

Feature -> Scenario -> Step
Feature -> Scenario Outline -> Example Row -> Step

JUnit will report each leaf as a test, and I'm not sure there is a way around that.

Regarding fireTestIgnored without a fireTestStarted - that sounds correct.

The JUnit runner still needs a lot of improvement, so any contributions are welcome.

@dgradl
Copy link
Contributor Author

dgradl commented Mar 19, 2012

I have 1.0.0.RC20 from maven for core and java, combined with a git clone of the JUnit project (which is RC21 I believe). I agree there may not be a way around the leafs being reported as tests. But I am looking into these things. I wanted to report a bug to track and it to get feedback from the community as to whether (if it were possible) it should not count steps as tests.

@aslakhellesoy
Copy link
Contributor

I don't think it's a problem to count leafs (steps) as tests. However, counting should obviously be correct and show 12/12 instead of 24/12.

I'm an IDEA user, so I haven't tested this on Eclipse yet. What exactly is a "run"? Is that something Eclipse reports? How is it different from a "test"?

@dgradl
Copy link
Contributor Author

dgradl commented Mar 19, 2012

With JUnit tests a Run equates to a test execution. So for example if you have a parameterized test (@RunWith(Parameterized.class)) with JUnit4 and there is a single method annotated with @test, but a set of 8 parameters. And it will list runs as 8. So it is executions of a test. I don't really think the steps are actually test executions in themselves, it takes the whole Given-When-Then to form an actual test, so that is why I don't like it counting each as a run. However, it is valuable to treat them as leafs in the execution tree, and to visually see where along that path it failed (e.g. an exception being thrown in a When step). So it may be something that is unavoidable. The main reason it even affected me is that I was trying to provide someone with a count of how many tests were being generated by the features and I could not use the Runs count to report that value. However, I can also count the number of scenario / example runs and derive that.

@mmalmeida
Copy link
Contributor

I remember having twice the count in the tests in Eclipse a while ago. Now I don't remember what I changed to get the correct count - it was definitely a random thing, not a feature.
Perhaps I posted the explanation either here or in the mailing list - I'll try to find it.

@aslakhellesoy
Copy link
Contributor

I think we all agree that it's important to have a leaf per step in order to see how execution went.

What exactly are you suggesting should be done in this ticket?

@dgradl
Copy link
Contributor Author

dgradl commented Mar 23, 2012

Leaf per step is fine. Submitted a pull request to address the double counting.

@aslakhellesoy
Copy link
Contributor

I'm reopening this because it still seems to be double quoting: https://groups.google.com/d/msg/cukes/huCNeimgU4w/UJ4-qhjXRFgJ

@aslakhellesoy aslakhellesoy reopened this Oct 4, 2012
@yurypetrov
Copy link

I've just started using cucumber-jvm. Works fine for us so far, thank you!

However, I am not sure why we need to have a leaf per step (not per scenario)? If we have a leaf per scenario will it be much worse in terms of understanding what step the test failed at? Any other reasons?

Maybe there's some thread that describes this in more details?

Thanks!

@aslakhellesoy
Copy link
Contributor

I agree completely that it was a bad decision to make steps be junit leaves. In a future version the leaves will be scenarios. If a scenario fails there will be enough info in the stack trace to figure out what step/stepdef failed. To improve the context we could also add a textual description of the scenario with steps in the exception message. It could even have ANSI colours in them, so that exceptions printed in ANSI terminals would show colours for exceptions. We would have to figure out a way to only send colours to TTY, not files.

@yurypetrov
Copy link

Thanks for the reply! Glad to hear we will move to scenario leaves in future!

Aslak, I suppose it will take time to make this change?
Are there any temporarily solutions you could recommend?

@aslakhellesoy
Copy link
Contributor

No, no temporary solutions I'm afraid. And yes, it will take a few months at least. It might happen before or after a new gherkin parser we're working on.

@ruslankhamitov
Copy link

Hi Aslak,

We are also using cucumber and faced with similar problem. It would also be extremely helpful for us to have leaf per scenario change implemented. I realize it's not a trivial change, but it could provide a lot more value for us by making test results more readable. We really hope this change will happen soon.

thanks!

@yurypetrov
Copy link

Hi Aslak!

Any updates on this one?

Thanks!

@aslakhellesoy
Copy link
Contributor

Unlikely to be fixed before gherkin3 is out. No ETA on that

1 similar comment
@aslakhellesoy
Copy link
Contributor

Unlikely to be fixed before gherkin3 is out. No ETA on that

@cdewangan
Copy link

Tagging me also to track this, Hoping for early resolution.

BTW, Thanks Aslak for JVM implementation of cucumber, its awesome.

@mayanksahai
Copy link

hi any update on this. recently moved from old cuke4duke to cucumber-jvm and like it quite a lot but this issue is still a bottleneck. i am using teamcity for build. any deadlines yet ?

@proninja
Copy link

Are there any updates or workarounds? This bug is a showstopper for me, because the number of tests is wrong, when they are run by the Team City or Jenkins.

@ArthurBilyk
Copy link

Hi guys,
Is there a workaround for this problem?
It's very sad that this bug won't be fixed :(

mpkorstanje added a commit that referenced this issue May 26, 2017
When interacting with cucumber in an IDE it is nice to see the step executions.
However presenting step executions to surefire as tests results in strange test
counts and weird reports.

 The --no-step-notifications options ensures steps are not included in
 descriptions  and no events are fired for the execution of steps.

 Related issues:
  - #263
  - #577
mpkorstanje added a commit that referenced this issue May 26, 2017
When interacting with cucumber in an IDE it is nice to see the step executions.
However presenting step executions to surefire as tests results in strange test
counts and weird reports.

 The --no-step-notifications options ensures steps are not included in
 descriptions  and no events are fired for the execution of steps.

 Related issues:
  - #263
  - #577
brasmusson pushed a commit that referenced this issue May 27, 2017
When interacting with cucumber in an IDE it is nice to see the step executions.
However presenting step executions to surefire as tests results in strange test
counts and weird reports.

 The --no-step-notifications options ensures steps are not included in
 descriptions  and no events are fired for the execution of steps.

 Related issues:
  - #263
  - #577
mpkorstanje added a commit that referenced this issue May 27, 2017
When interacting with cucumber in an IDE it is nice to see the step executions.
However presenting step executions to surefire as tests results in strange test
counts and weird reports.

 The --no-step-notifications options ensures steps are not included in
 descriptions  and no events are fired for the execution of steps.

 Related issues:
  - #263
  - #577
mpkorstanje added a commit that referenced this issue May 27, 2017
When interacting with cucumber in an IDE it is nice to see the step executions.
However presenting step executions to surefire as tests results in strange test
counts and weird reports.

 The --no-step-notifications options ensures steps are not included in
 descriptions  and no events are fired for the execution of steps.

 Related issues:
  - #263
  - #577
mpkorstanje added a commit that referenced this issue May 27, 2017
When interacting with cucumber in an IDE it is nice to see the step executions.
However presenting step executions to surefire as tests results in strange test
counts and weird reports.

 The --no-step-notifications options ensures steps are not included in
 descriptions  and no events are fired for the execution of steps.

 Related issues:
  - #263
  - #577
@mpkorstanje
Copy link
Contributor

This will be fixed with #1135.

@lock
Copy link

lock bot commented Oct 25, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests