On Apr 30, 2012, at 11:04 AM, Yaroslav Halchenko wrote: >With such a massive automated "packaging" it would be great if from day >0 you would think about adding build-time testing into the >pipeline. It should be quite easy to discover if module carries any >unittests (grep for unittest ;) ) and what should be the way to run them >(many modules provide .test(), or are testable with 'nosetest module'). >It would provide you assurance that generated packages are usable by the >users, thus reduce future frustration / bug reports about broken >packages.
*Really* excellent suggestion. I think you're going to have to build in a bunch of heuristics to find package tests, but it's also worth it. Some strategies include: - Look `test_suite` key in setup.py, and if found, run `python setup.py test` - Try `python -m unittest discover` - Look for tox.ini and run `tox` (see bug 664759) - Try `nosetest` - Look for variations of a `runtests.sh` script in the top level directory or `tests` subdirectory. Probably more I can't think of right now. Yeah, I wish the Python world had more consistency. I'm still hoping `packaging` will at least include some metadata on how to run a package's tests. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430111958.3bac1...@resist.wooz.org
