-
Notifications
You must be signed in to change notification settings - Fork 8
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
Support pytest (#50) #57
Conversation
…lthchecks. Include entry point.
… about in pytest internals.
…tion for `--healthcheck` switch.
Thank you @ftobia for this pull-request! I'm doing the review ASAP.
Moved these changes to #62, so that the changelog is more readable.
Do you have an idea about how to add tests? I currently see the following options:
If you have not written tests by your side yet, I think I will try to write them. What do you think? |
I haven't written tests for the pytest code I wrote. I have some ideas of how to do it. The easiest way is to Also there is an undocumented _pytester plugin included in pytest, for testing pytest plugins. This is useful if you want to test pieces that are smaller than end-to-end behavior. I don't think you need to use two test runners (both nose and pytest). I think this corresponds with your option 2. I made this pull request without tests because I didn't want to hold up a pull request any longer. Over the next few weeks I'm hoping to have the time to write (or flesh out) tests for pytest integration, but I can't commit to anything, and I figured even without tests the code could be helpful. |
@ftobia: do you think the That said, I am not used to pytest plugins, so I may miss a best practice. |
Note for later (when this feature is merged and released): register this plugin to http://pytest.org/latest/plugins_index/index.html |
I don't think something like a On one hand, I am sensitive to "there should be one, and preferably only one, obvious way to do it"; and this helper means extra code and extra tests. On the other hand, in places where this command will be used, potentially by non-Python people or non-pytest people, I think e.g. I do think a helper like I'm happy to go with whatever you decide is best. |
I understand your point of view. But I do not have enough feedback from community to guess what option would be best... and have to make a biased choice :(
I think running tests without capturing healthchecks is a common and important use case, because healthchecks can be captured by test runners. It is a side effect of writing healthchecks as special kind of tests. So when you introduce healthchecks, you may like to exclude healthchecks from your (unit|integration|functional) test suite. In doubt, I'd tend to keep the feature as simple as possible for a first release, i.e. " Note: I'm working on a talk about hospital for DjangoCon EU... hoping we get some feedback there! |
Sounds good to me. Cool to hear you're giving a talk on hospital at DjangoCon EU! I'll check it out when it gets posted online. |
Adds support for running healthchecks with py.test.
Also moves the tests out of the "hospital" package, so hospital won't have a pytest dependency.
This pull request does not include tests for this functionality.