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

Cucumber returns the same exit code when specs are failing and when command execution is failing #844

Closed
ciembor opened this issue Apr 27, 2015 · 7 comments

Comments

@ciembor
Copy link
Contributor

ciembor commented Apr 27, 2015

When all cucumber scenarios pass it returns 0 exit code. When some of scenarios fails, cucumber returns 1 exit code. When there is wrong argument passed, or something else crashes cucumber, the exit code is 1 as well. Because of that it's not possible to distinguish if cucumber run all specs and some are failing or if some shit happend.

Real life usage of this feature? Recording failing specs and reruning them on continuous integration system.

@ciembor ciembor changed the title Cucumber returns the same exit code when specs fails and when command execution fails Cucumber returns the same exit code when specs are failing and when command execution is failing Apr 27, 2015
@aslakhellesoy
Copy link
Contributor

Aren't you able to detect the reason by looking at the output? Do you have any suggestions about how to improve this?

@ciembor
Copy link
Contributor Author

ciembor commented Apr 27, 2015

I can parse the output to detect my specific problem, but it isn't generic solution. Here is more info about exit statuses:

http://www.gnu.org/software/libc/manual/html_node/Exit-Status.html

Cucumber is very specific application, which should fail even if it actually works. So I don't know if it is possible to follow any standard convention. However status 0 is always success and every other is an error. So the simplest thing is to define at least 3 exit statuses: 0 - success, 1 - cucumber error, 2 - failing specs. But there might be some conventions I don't know. I'm curious what other people think about it.

@mattwynne
Copy link
Member

Programs that perform comparison use a different convention: they use status 1 to indicate a mismatch, and status 2 to indicate an inability to compare

In cucumber’s context, that sounds like 1 to indicate a test failure, and 2 to indicate an inability to run the tests.

As well as bad CLI arguments exit status 2 could represent, for example, undefined steps in strict mode, or exceptions raised when loading support code / step defs.

I would accept a PR for this, but I can’t see it being prioritised by the core team, sorry.

@ciembor
Copy link
Contributor Author

ciembor commented Apr 28, 2015

From implementation point of view it would be cleaner to have 1 for application error (this is default in Ruby raise) and exit 2 when tests are failing. But maybe there is some way to force returning 2 bu default.

// edit

Oh, I looked at the code and it looks easier than I thought :). I will create some pull request soon.

@ciembor
Copy link
Contributor Author

ciembor commented Apr 30, 2015

As you can see I made a pull request. I don't know your workflow, I hope it should go to the master branch. I would be glad to hear your opinions.

cucumber/common#845

@mattwynne
Copy link
Member

Thanks @ciembor! I'll close this ticket in favour of the PR.

@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

3 participants