On 16/02/2022 17:41, Jean-Paul Calderone wrote:
On Fri, Feb 11, 2022 at 5:36 PM Jean-Paul Calderone <exarkun@twistedmatrix.com <mailto:exarkun@twistedmatrix.com>> wrote:
I know that you can hack around this situation roughly like this:
python -m coverage run -m twisted.trial ...
but this has some shortcomings.
1. If trial --coverage exists shouldn't it be the *good* option? 2. python -m coverage run -m twisted.trial -jN ... is a bad time. How about some coverage measurement that's multi-core friendly? It's a /real/ drag going from a 30 second no-coverage test run using 16 cores to a 15 minute coverage-measuring run on a single core.
Does anyone agree that this is something short of an ideal situation? Is anyone interested in helping address it?
Anyone?
At this point, it feels like any available energy could be more usefully employed in getting a pytest plugin that really supported the Twisted reactor in place. Re-inventing wheels like coverage just doesn't seem sensible at this point. I've noticed trial itself routinely leaks failures across tests, resulting in some random test down the line spuriously failing. I've hacked up tooling to run `trial -u` for 10s for each test case to try and find these happening, but feels like something the test runner should really cater for. I guess a lot of this, and indeed a non-testing use case I have, would be served be asyncio-style event loops rather than one single monolithic and unrestartable reactor. This isn't meant to come across as negatively as it may well seem; there's a reason I haven't ripped Twisted out of the major project I'm involved in where it's used, but Twisted as a whole and trial in particular really are feeling their 20yrs of age ;-) cheers, Chris