Open tomprince opened 3 years ago
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.
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 thepytest_pyfunc_call
hook suggesting this change: https://github.com/pytest-dev/pytest-twisted/blob/cc03b1102ebe51a04c80016b03800ff394e2e2b8/pytest_twisted.py#L357-L363This is perhaps a duplicate of #64.