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

Add flag which makes pytest to return 0 exit code if no test functions were executed. #5689

Closed
WloHu opened this issue Aug 3, 2019 · 7 comments
Labels
type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature

Comments

@WloHu
Copy link

WloHu commented Aug 3, 2019

Followup from #812 (comment) and I'm aware about discussion in #500 .

  • a detailed description of the bug or suggestion

Title.
With this flag added calling pytest --the-flag will return 0 exit code if no test function were found.

There are 2 cases to consider:

  • there is no test functions in directory,
  • all tests were deselected.

I only care about the 1st scenario because my use case it to configure CI with tox where testing is one of build steps and I want to have that step in place even if there are no tests yet. Without this flag I would have to do something (e.g. add - pytest in tox.ini) and redo that after some tests were added or perform additional bash scripting which would analyze the test directory and returned code and possibly change the return code accordingly.

Also given that people from other testing tools e.g. unittest are used to scenario "if there is no tests there is no reason to fail" so this flag will give everyone an option about how pytest should behave.

The 2nd mentioned scenario can also have such option but on one side you want to treat "all tests were deselected" as a way to prevent errors. On the other side, why don't give users an option to configure pytest to their needs? Both, being arbitrary or open for options, have good reasons so it's hard for me to decide on that one.

Furthermore there may come a question "if you can configure this return code then why shouldn't it be possible to configure all of them?". I only want to mention this because it is an extention to this issue and probably requires a separate feature request.

  • pytest and operating system versions

pytest=5.0.1
OS=Arch Linux (Linux-5.2.2-arch1-1-ARCH-x86_64-with-glibc2.2.5)

@RonnyPfannschmidt
Copy link
Member

-1 on this in core, this can be in a plug-in or in a wrapper script

@nicoddemus nicoddemus added the type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature label Aug 3, 2019
@nicoddemus
Copy link
Member

Thanks @WloHu for following up.

Indeed a plugin might be the best place for this. Would that solve the problem for you @WloHu?

@nicoddemus
Copy link
Member

Hah, in fact such a plugin already exists:

https://github.com/yashtodi94/pytest-custom_exit_code

@nicoddemus
Copy link
Member

Mentioned the plugin in #5690 so it is more visible.

@WloHu
Copy link
Author

WloHu commented Aug 3, 2019

@nicoddemus Yup that works. Thanks!

Honestly I didn't think about searching plugin for that because it seemed to me like close-to-the-core functionality. Anyway, I'm closing this.

@WloHu WloHu closed this as completed Aug 3, 2019
@nicoddemus
Copy link
Member

close-to-the-core functionality

pytest is suprisingly extensible. I suggest to take a look at the 31-lines plugin code if you are interested 😉

https://github.com/yashtodi94/pytest-custom_exit_code/blob/master/pytest_custom_exit_code.py

nicoddemus added a commit to nicoddemus/pytest-custom_exit_code that referenced this issue Aug 3, 2019
Hi,

Just discovered this through pytest-dev/pytest#5689, nice work!

Changing the import to no longer use the internal name, given that `ExitCode` is now public API.
@yashtodi94
Copy link
Contributor

yashtodi94 commented Aug 4, 2019

An earlier discussion on this issue just for reference: pytest/issues#2393

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: proposal proposal for a new feature, often to gather opinions or design the API around the new feature
Projects
None yet
Development

No branches or pull requests

4 participants