At 05:36 PM 1/5/2007 +0200, David Fraser wrote: >How would this work if for example, you're using an alternative testing >framework (like py.test) for your test?
If I understand correctly, py.test simply won't be usable for this scenario, because it assumes tests are files first and modules second, if at all. It's not equipped to discover tests that are inside eggs, which is the whole point of this proposal. Integrating py.test with the "setup.py test" command, on the other hand is possible and relatively simple; just create a unittest-compatible test suite object that wraps py.test, and a test loader class that grabs the necessary arguments from the test_suite argument string. No modifications to setuptools are required, you just provide appropriate values for the test_suite and test_loader arguments to setup(). But the proposal being discussed is for tests that are actually *installed* somewhere, and thus might be in a zipfile. >Great, so at least the testing framework could be declared as a dependency For "setup.py test", this is already possible via the 'tests_require' argument to setup(). What's being discussed here is a standard for *installed* tests -- that is, tests that a developer has chosen to make part of their projects's installed code. The existing "setup.py test" subsystem requires a *source* distribution, not installed code. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig