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

Don't run unmarked tests in the reactor greenlet. #141

Open
tomprince opened this issue Aug 16, 2021 · 1 comment
Open

Don't run unmarked tests in the reactor greenlet. #141

tomprince opened this issue Aug 16, 2021 · 1 comment

Comments

@tomprince
Copy link

I have a project using pytest-twisted, and I'd like to write some tests using hypothesis' stateful testing. Since the control-flow of stateful testing is handled by hypothesis, I use pytest_twisted.blockon in the tests to interact with twisted.

However, this doesn't work by default, as pytest-twisted forces every test function to run in the reactor greenlet. There is a comment in the pytest_pyfunc_call hook suggesting this change:

def pytest_pyfunc_call(pyfuncitem):
"""Interface to async test call handler."""
# TODO: only handle 'our' tests? what is the point of handling others?
# well, because our interface allowed people to return deferreds
# from arbitrary tests so we kinda have to keep this up for now
_run_inline_callbacks(_async_pytest_pyfunc_call, pyfuncitem)
return not None

This is perhaps a duplicate of #64.

@altendky
Copy link
Member

Based on the comment it seems the tension is simply between moving forward to a sensible place where you explicitly request pytest-twisted handle's your tests and the desire to not break backwards compatibility... bah. Perhaps a sensible transitional tool would be an ability to explicitly mark a test to not be handled by pytest-twisted? Would you consider that a useful and reasonable middle ground to address this in the short term?

I'll go ahead and note that while I do have a little familiarity with hypothesis, I don't have any with their stateful testing. As such, my commentary here, at least for now, won't have any hope of offering any specific insight about what a good way to integrate that with pytest-twisted would be. Though, having to use pytest_twisted.blockon() strikes me as a thing that we would like to avoid as much as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants