firstname.lastname@example.org wrote: [...]
Twisted application does, and which is not _really_ supported by the framework: re-start the reactor repeatedly.
Eventually, 'trial' itself will not do this, and will behave as a "normal" Twisted application. 'trial' will, as stated by the ticket I just linked to, still support other test runners by having a 'run' method that starts and shuts down the reactor, but it won't be used internally. The main reason to do this is that there are various tools which would be nice to use Twisted functionality in-process with the tests for reporting results. Doing that will probably remain a trial- exclusive feature, because other test runners will necessarily need to completely shut down the reactor at the end of each test.
I've expressed this opinion before, but FWIW:
I don't think this is the right approach. The right approach is to fix Twisted to support multiple simultaneous reactors, so that your Twisted test runner that wants to do stuff with a reactor is isolated from the tests, and vice versa. The tests should then use a fresh reactor for each test. It's simple and robust.
The reactor can't be comprehensively unittested until multiple reactors/restartable reactors are supported anyway, so it should be done. This would also make it possible to consider testing multiple different reactor implementations in a single test run.
I see only a continuation of the problems that have been plaguing Trial for *years* with your approach.