-
Notifications
You must be signed in to change notification settings - Fork 233
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
How to get pending steps to not be seen as failures? #129
Comments
This is done by design. What exactly are your expectations? |
I would expect the scenario to report scenarios that have pending steps to report their overall status as pending. The command-line reporting reports scenarios as failed, passed, undefined, or pending:
Or in this case:
The built-in html formatter also shows scenarios as passed, failed, or pending. I have attached a sample. I've also attached a screenshot showing what I am seeing with the cucumber-reports-plugin. |
Here's another html report with a single scenario that is pending. |
Sorry but I don't see string enough reason for changing default behave |
Thanks. I'll probably just change it in my fork then. Would you mind pointing me towards where the logic to calculate the overall results are computed? |
But am planning to skip few scenarios so it would be greatly helpful if you add column for pending in scenarios and also if you could tell me the way to modify plugin code also should be fine...but i need it badly...thanks |
I have made changes in my fork of cucumber-reporting that do almost all that is needed. The main reports now show pending and undefined steps/scenarios/features. The only thing I have not implemented is the trend reporting. If you'd like to get the code, see pull request 636: damianszczepanik/cucumber-reporting#636 |
When executing cucumber tests in the strict mode, pending steps will fail the test so rendering pending as failures not strictly speaking wrong. I guess what you're looking for is to mimic this strict mode in the report. Semantically it is wrong to use Pending to mean not executed due to failing preconditions. However once cucumber-jvm 2.0.0 is out you'll be able to use Junit Assume to do just this. Can't provide an eta. on that but we do have snapshot releases.
|
Thank you for update!!!
…On Tue, Jun 13, 2017 at 2:03 PM mpkorstanje ***@***.***> wrote:
I've recently noticed that when a scenario has a step that returns
'pending' that the cucumber reports show the scenario as 'failed'. Is there
a way to change that behavior? We use 'pending' to indicate that a certain
dependency is not configured during a particular test run, and this is an
expected condition.
When executing cucumber tests in the strict mode, pending steps will fail
the test so rendering pending as failures not strictly speaking wrong.
Semantically it is wrong to use Pending to mean not executed due to
failing preconditions. However once cucumber-jvm 2.0.0 is out you'll be
able to use Junit Assume
<http://junit.org/junit4/javadoc/4.12/org/junit/Assume.html> to do just
this.
Can't provide an eta. on that but we do have snapshot releases.
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
<repository>
<id>sonatype-snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#129 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARXxMGMT4GeSJFHLATV5I72TEuBgXHkRks5sDs8NgaJpZM4MXY8d>
.
|
I have done woraround for this from excel ,am not including that feature
itself for run.
…On Tue, Jun 13, 2017 at 2:03 PM mpkorstanje ***@***.***> wrote:
I've recently noticed that when a scenario has a step that returns
'pending' that the cucumber reports show the scenario as 'failed'. Is there
a way to change that behavior? We use 'pending' to indicate that a certain
dependency is not configured during a particular test run, and this is an
expected condition.
When executing cucumber tests in the strict mode, pending steps will fail
the test so rendering pending as failures not strictly speaking wrong.
Semantically it is wrong to use Pending to mean not executed due to
failing preconditions. However once cucumber-jvm 2.0.0 is out you'll be
able to use Junit Assume
<http://junit.org/junit4/javadoc/4.12/org/junit/Assume.html> to do just
this.
Can't provide an eta. on that but we do have snapshot releases.
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-junit</artifactId>
<version>${cucumber.version}</version>
<scope>test</scope>
</dependency>
<repository>
<id>sonatype-snapshots</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#129 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARXxMGMT4GeSJFHLATV5I72TEuBgXHkRks5sDs8NgaJpZM4MXY8d>
.
|
This implementation seems quite reasonable, as Pending status tells us something was not yet implemented or is ommited on purpose. If something is wrong with stepdef(therefore scenario), there are failed and undefined statuses. So, +1 vote to see this in official implementation of plugin. We have our own BDD framework and we didn't have Pending exception yet, so I'm implementing it right now and it kind of depends on this plugin what statuses will I pass to scenario level. |
My requirement was skipping the feature if I do not want,But I implemented
it using pre requisite approach.
If any one interested in approach ,pls ping me here.
Thanks,
Karthik
…On Tue, Jun 27, 2017 at 11:40 AM maultosar ***@***.***> wrote:
This implementation seems quite reasonable, as Pending status tells us
something was not yet implemented or is ommited on purpose. If something is
wrong with stepdef(therefore scenario), there are failed and undefined
statuses. So, +1 vote to see this in official implementation of plugin.
We have our own BDD framework and we didn't have Pending exception yet, so
I'm implementing it right now and it kind of depends on this plugin what
statuses will I pass to scenario level.
So, is there any chance this will be implemented or I should not hope for
this useful feature?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#129 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARXxMLt5z8E0mCOmJ7rMKQ4I-18LsaRxks5sISKGgaJpZM4MXY8d>
.
|
Looks like there is need to add feature that was removed time ago because some problems with consistency. I need to think it over again |
It would be a very helpful feature. Thanks:) |
This would be helpful for my project too :) |
+1 for this feature requirement |
+1 from me The result view shown by @SteveDonie ( comment above / PR 636 ) would be exactly what we need. "undefined" and "pending" should be differentiated from "failed":
Choosing between "undefined" and "pending" could be subject to discussion and local interpretation, but at least they should be visible up to feature level (instead of just "failed"). |
Would it be OK to add tow new flags: one for undefined and second for pending so it defines if the steps should be counted as passed or failed? |
@damianszczepanik I don't think that your suggestion of new flags meets my needs at all. I don't want a feature or a scenario to be limited to a passed or failed state - I actually like knowing that a scenario is 'pending' or 'undefined' - I see these as communicating more richly what the state of things is. |
What when scenario has steps with different statuses? |
Of course we have to have clearly defined aggregation rules.
We should bring the statuses into an order, and then take the worst (min or max) value.
E.g.:
- 0: passed
- 1: pending
- 2: undefined
- 3: failed
The outcome of a scenario then would simply be maximum of step results.
And same should hold for features which would be evaluated based on their worst scenario.
Am 21. Oktober 2017 11:01:10 MESZ schrieb Damian Szczepanik <[email protected]>:
…What when scenario has steps with different statuses?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#129 (comment)
|
@KLBonn If you look at the diff in pull request 636, you'll see that is exactly what I have done. |
Hi All,
Am not sure this is right tag,but
I would like to contribute following feature to this plugin ,please suggest
When I execute examples in feature in parallel
I have writtent an utility to merge all jsons according to this report and
show the result appropriately.
Thanks
Karthik
…On Sat, Oct 21, 2017 at 10:19 AM Steve Donie ***@***.***> wrote:
@KLBonn <https://github.com/klbonn> If you look at the diff in pull
request 636
<damianszczepanik/cucumber-reporting#636>, you'll
see that is exactly what I have done.
See
https://github.com/damianszczepanik/cucumber-reporting/pull/636/files#diff-8350411954262e85f9d3bee0c77b2879
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#129 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARXxMIztZuodPsDS76QI4_ondavL9osWks5suf1XgaJpZM4MXY8d>
.
|
Based on https://github.com/damianszczepanik/cucumber-reporting/blob/master/src/main/java/net/masterthought/cucumber/json/support/Status.java#L17-L19 I'm not really sure if this is clear to everybody what is the relation between those three. So I have concern if by introducing three new statuses for scenarios and features we introduce some doubts what is the different between pending and skipped for feature. It is not as clear as for steps which is very small unit. |
Yes, looking at the code of PR 636, we seem to share the same idea here :-) @damianszczepanik Maybe we could introduce a flag / feature toggle for that new behaviour? Then anyone confused by differentiated statuses can drop down to showing every non-passing scenario/feature as failed. Of course, a description / definition of the meaning for each status should be part of the documentation, anyway. |
Hi , Thank you. |
Probably other statuses are set to zero while your report has more. Validate other statuses. |
Hi, |
OK, now I understand, this is duplicate of damianszczepanik/cucumber-reporting#636 |
The referenced pull request, damianszczepanik/cucumber-reporting#636 is going into the Datical fork, not jenkinsci. Why was this issue's status changed to closed? |
I've recently noticed that when a scenario has a step that returns 'pending' that the cucumber reports show the scenario as 'failed'. Is there a way to change that behavior? We use 'pending' to indicate that a certain dependency is not configured during a particular test run, and this is an expected condition.
I have tried setting the report plugin configuration "Number of pending steps" to a very high number (99999) and that does not seem to affect the result.
The text was updated successfully, but these errors were encountered: