homepage

Add a test command in distutils, ala setuptools

Should default to test discovery if no arguments are supplied.
Valid arguments: "testrunner", "tests" or "testsuite".
Default testrunner is unittest of course. "tests" / "testsuite" to be of the form: "package.module.suitename" (or just "package.module").

For what it's worth, I'm trying to adapt the setuptools command of the same name in a feature branch called "mbh/adding-test-command" --> http://bitbucket.org/meatballhat/distutils2/
Not sure how the roundup/<external tracker> split is usually handled, so sorry if I'm doin it wrong :-/

Adapting the setuptools command is a great way to start of course. Please see my note about using unittest/unittest2 test discovery as a default command if unitest2 is available and no test_suite is specified. I'm very happy to help with this.

Should I assume that unittest2 is an installation requirement of distutils2, or is it preferable to try using unittest2 and falling back to a custom TestLoader? Sorry if I'm reading too much into this :-/

unittest2 is the name of the independent release of the improved unittest package in 2.7’s and 3.2’s stdlib.

@merwok I know ;-) ... should I assume that it's an installation requirement a la `install_requires=['unittest2']`, or do::
 try:
 load_tests_with_unittest2()
 except ImportError:
 load_tests_with_custom_test_loader()
?

Not a unittest expert, but I suspect that usual test for features will work:
try:
 from unittest.something.discovery import Loader
except ImportError:
 from unittest2.something.discovery import Loader
Adding Konrad to nosy, since adding new commands will be his GSoC work.
(Also adjusting versions and removing the gsoc keyword that means "Issue is a good candidate for Google’s Summer of Code", not "Issue part of an accepted GSoC project")

unittest2 is used for distutils2 development, but *not* a required dependency for *using* distutils2 (if I understand correctly(.
Well, if there is no test runner and no test suite specified but the test command is invoked then the steps should probably be something like:
* If Python version 2.7+ or 3.2+ then use test discovery from unittest
* If Python version 3.0, 3.1 or 2.6- then attempt to import unittest2 and do test discovery
* Otherwise do nothing
Test discovery is done with unittest(2).TestLoader.discover(...)
If a specific test runner or suite is provided then distutils2 should use those and need not attempt test discovery (again - my understanding).
So test discovery is a useful default if no test command is configured for a project. We may also want ways to configure that (for example allow a project to have test discovery for its test command but provide a different pattern for finding test files).

Documentation for unittest.TestLoader.discover(...) is at:
http://docs.python.org/dev/library/unittest.html#unittest.TestLoader.discover 

@mfoord thank you for the clarification! :)

@Eric: I asked for the gsoc keyword to make my work easier in bug triage. And as a matter of fact, it means that the issue part of the GSoC.

Implemented by Konrad and merged into the main repo.