The test suite is the canonical usage of the library.
We are uncovering problems related to pre-existing state, which we are mostly shielded from because pytest avoids pre-existing state, and is quite a mature test runner.
A good way to uncover other pre-existing state problems is to run (a subset of) the test suite on multiple test runners. This would mean using unittest style classes for some of it, and would mean those other test runners might not be exposed to all of the tests & features so some of the more complicated bits might be skipped and the bugs not found.
The test suite is the canonical usage of the library.
We are uncovering problems related to pre-existing state, which we are mostly shielded from because pytest avoids pre-existing state, and is quite a mature test runner.
A good way to uncover other pre-existing state problems is to run (a subset of) the test suite on multiple test runners. This would mean using
unitteststyle classes for some of it, and would mean those other test runners might not be exposed to all of the tests & features so some of the more complicated bits might be skipped and the bugs not found.Another important reason to have some unittest compatible tests is getting
pytestrunning on all python implementations is prohibitive as noted at https://github.com/bskinn/stdio-mgr/issues/81#issuecomment-530179250