[issue14408] Support the load_tests protocol in the stdlib tests

Éric Araujo added the comment: > Of course this would remove the possibility to run things like “../../python > test_shutil.py” I was wrong: we would just have the usual two-liner invoking unittest.main. What would be broken is running via regrtest if we remove test_main functions (IIRC); t

[issue14408] Support the load_tests protocol in the stdlib tests

R. David Murray added the comment: Your presumption is probably correct, however if that is the premise of the patch it is incorrect in detail, since we've already fixed test_queue specifically to be runnable with -m unittest without adding a load_tests. I haven't looked at the other modules

[issue14408] Support the load_tests protocol in the stdlib tests

Michael Foord added the comment: Yes, it would be preferable if unittest could load the set of test classes for each of these test modules without *requiring* a load_tests function. Each test module will need looking at to see if the standard set of test classes exported by the module is the

[issue14408] Support the load_tests protocol in the stdlib tests

Matt Joiner added the comment: I think if you can correctly construct the same test case list using discovery then that's far superior. But I haven't tried this, and don't know if you can correctly predicate the support classes using only class decorators. --

[issue14408] Support the load_tests protocol in the stdlib tests

Éric Araujo added the comment: I’m a bit disappointed to see that the files after the change are as long. I hoped we could avoid explicitly listing test cases, thanks to auto-discovery of TestCase subclasses combined with skips for specific platforms or optional modules. Of course this woul

[issue14408] Support the load_tests protocol in the stdlib tests

Changes by Michael Foord : -- title: Support the test_cases protocol in the stdlib tests -> Support the load_tests protocol in the stdlib tests ___ Python tracker ___ __