Robert Collins added the comment: "say, something to run a test until failure, or to watch for reference leaks, or to run tests in multiple processes :-))"
I think a few complimentary things. unittest extensability currently requires a new CLI entry point for each thing. I'd like to fix that. The actual plumbing is fairly extensible, though its not always obvious. I'd like to fix that too - without any global state getting involved. Of the things you mention, running a given command line until failure and checking for reference leaks are both straight forward, very common requests (as is the gc check) and I'd like to see those implemented as extensions shipped in the stdlib. Running in parallel becomes important when one is doing slow (e.g. functional) tests with unittest, and I think thats important to support. It is however much harder to do well: some of the current idioms that have snuck in (like the handling of stdout/stderr capturing without the buffer flag) are not well matched to the needs of reporting on concurrent tests to users. I'm not in any way opposed to a good implementation, but it would need to be good I think - there's not much point having a poor implementation, given the rich set of parallel test runners that are out there that already build on the unittest core (green, nose, testrepository just for starters). The only unique audience for stdlib test facilities is the stdlib itself and I think a better way to solve that is to enable the use of alternative runners for our own tests (moving them to be a little cleaner should enable that) - and then the point where it matters is really 'when buildbots would be enough faster to make a di fference'. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17908> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
