On Jul 04, 2011, at 08:20 AM, Robert Collins wrote: >unittest2 is still a unittest runner at heart; the basic model is >sound to scale up to N processes and so forth (see tox or >testrespository for instance), but compatibility with arbitrary ways >of running is pretty tricky. See for instance the guts of the >following three runners: trial, django and zc.testing.testrunner. > >All I'm saying is don't hold your breath: those communities could have >plugged into the original unittest compatibly but didn't - I think it >needs to be massively more clear *how* to do so, and on older Pythons >for those communities - they don't live on the edge ;) - for >one-runner-with-plugins to reach that point. > >As a data point, in the java world multiple runners is still the case, >with some common interop on output format. I'm actually fine with all that diversity. I'd just like to promote the interface `python setup.py test` (or `pysetup test`) as the preferred way of running the test suite for a package. It doesn't even have to run the full test suite (e.g like Python's own -uall flag), but it should provide a decent smoke test for any package. Sure, there will be packages that can't or won't support this standard, but I think the majority of packages can, and should. A carrot approach here would attach some kind of gold star to a package for those that have such a test suite and pass it at package build time. The stick approach would entail having the Debian tools default to running that command and FTBFS any package that fails its test suite. We can always special case the special cases. -Barry
Attachment:
signature.asc
Description: PGP signature