[Discussion] Customisibility for pytest-twisted

[tyerq]

I have a fairly specific use case with my project:
I'm using both Twisted (with asyncioreactor setup) and native asyncio awaits somewhat interchangeably, but when it came to testing, I've gotten into troubles with pytest_twisted's and pytest_asyncio's incompatibility.

The issue is that when using pytest_twisted it becomes impossible for pytest_asyncio to make a new loop for every test, since it's basically running inside a global twisted loop.

So basically, for my use case I would want to have pytest-twisted applied only in tests I need it to be applied and making a separate loop for every test and getting rid of it after test is done.

I've dealt with this by doing some tinkering, which resulted in:

1. introducing pytest.mark.twisted that is checked by pytest_pyfunc_call that skips if the mark is absent;
2. adding a --twisted-marked-only cmdopt that pytest_collection_modifyitems checks and if it's False (which it is by default to preserve current behaviour) adds the twisted mark to any test that doesn't have it already;
3. adding a --twisted-scope cmdopt and a twisted_greenlet_fixture_factory function that is called in pytest_configure that depending on the scope:
   • behaves as if it wasn't there (except the resulting fixture isn't autouse) if scope="session" (default);
   • makes a fixture with the specified scope that dels twisted.internet.reactor before and after creating a new reactor and mocks it with it's created reactor for the users otherwise;
4. in pytest_runtest_setup adding the twisted_greenlet fixture for every test that has the pytest.mark.twisted (like autouse, that you can opt out of :з ).

I'll make a pull request for it, but the real question is:
Is it of any use for anybody except me and could this the direction the project goes in?

[tyerq]

OK, so after some more testing, any scope beside session doesn't work well at all.
If something in the test-suite imports reactor indirectly at module level it can get hold of the wrong reactor. + the deal with it being a singleton and trying to force in to not be one ends up very messy and questionable.
As I can see, it's a design-choice of Twisted, that we just have to live with..

So 3 ends up useless, but 1,2 and 4 look like a good idea to me, since it gives more control to the user over which tests are for twisted and which are not.

[altendky]

@tyerq, I can't promise I have a lot of time for this but I would be interested in seeing the PR. More compatibility is good, we'll just have to look at what it takes to get it.

We already have to decorate inlineCallbacks tests and async/await tests. You are using pytest.mark.twisted for regular function tests which are using deferreds directly?