Issue 8324: add a distutils test command (original) (raw)
Issue8324
Created on 2010-04-05 23:19 by tarek, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (13) | ||
---|---|---|
msg102426 - (view) | Author: Tarek Ziadé (tarek) * ![]() |
Date: 2010-04-05 23:19 |
Add a test command in distutils, ala setuptools | ||
msg102427 - (view) | Author: Michael Foord (michael.foord) * ![]() |
Date: 2010-04-05 23:31 |
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"). | ||
msg105362 - (view) | Author: Dan Buch (meatballhat) | Date: 2010-05-09 01:59 |
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/ split is usually handled, so sorry if I'm doin it wrong :-/ | ||
msg105376 - (view) | Author: Michael Foord (michael.foord) * ![]() |
Date: 2010-05-09 09:10 |
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. | ||
msg105382 - (view) | Author: Dan Buch (meatballhat) | Date: 2010-05-09 12:10 |
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 :-/ | ||
msg105383 - (view) | Author: Éric Araujo (eric.araujo) * ![]() |
Date: 2010-05-09 12:13 |
unittest2 is the name of the independent release of the improved unittest package in 2.7’s and 3.2’s stdlib. | ||
msg105384 - (view) | Author: Dan Buch (meatballhat) | Date: 2010-05-09 12:16 |
@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() ? | ||
msg105386 - (view) | Author: Éric Araujo (eric.araujo) * ![]() |
Date: 2010-05-09 12:21 |
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”) | ||
msg105389 - (view) | Author: Michael Foord (michael.foord) * ![]() |
Date: 2010-05-09 12:40 |
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). | ||
msg105390 - (view) | Author: Michael Foord (michael.foord) * ![]() |
Date: 2010-05-09 12:41 |
Documentation for unittest.TestLoader.discover(...) is at: http://docs.python.org/dev/library/unittest.html#unittest.TestLoader.discover | ||
msg105393 - (view) | Author: Dan Buch (meatballhat) | Date: 2010-05-09 12:54 |
@mfoord thank you for the clarification! :) | ||
msg105418 - (view) | Author: Tarek Ziadé (tarek) * ![]() |
Date: 2010-05-09 21:27 |
@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. | ||
msg115773 - (view) | Author: Éric Araujo (eric.araujo) * ![]() |
Date: 2010-09-07 15:18 |
Implemented by Konrad and merged into the main repo. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:59 | admin | set | github: 52571 |
2010-09-07 15🔞51 | eric.araujo | set | status: open -> closedresolution: accepted -> fixedmessages: + stage: needs patch -> resolved |
2010-07-01 13:42:56 | eric.araujo | set | stage: needs patchresolution: acceptedversions: - Python 3.3 |
2010-05-24 21:46:29 | barry | set | nosy: + barry |
2010-05-09 21:27:40 | tarek | set | keywords: + gsocmessages: + |
2010-05-09 12:54:12 | meatballhat | set | messages: + |
2010-05-09 12:41:06 | michael.foord | set | messages: + |
2010-05-09 12:40:16 | michael.foord | set | messages: + |
2010-05-09 12:23:09 | eric.araujo | set | keywords: - gsoc |
2010-05-09 12:22:54 | eric.araujo | set | nosy: + konryd |
2010-05-09 12:21:02 | eric.araujo | set | messages: + versions: + Python 2.6, Python 2.5, Python 3.1, Python 2.7, Python 3.2, Python 3.3 |
2010-05-09 12:16:36 | meatballhat | set | messages: + |
2010-05-09 12:13:25 | eric.araujo | set | messages: + |
2010-05-09 12:10:57 | meatballhat | set | messages: + |
2010-05-09 09:10:23 | michael.foord | set | messages: + |
2010-05-09 01:59:56 | meatballhat | set | messages: + |
2010-05-01 01:38:05 | meatballhat | set | nosy: + meatballhat |
2010-04-06 22:47:54 | eric.araujo | set | nosy: + eric.araujo |
2010-04-06 11:41:29 | zubin71 | set | nosy: + zubin71 |
2010-04-05 23:45:22 | giampaolo.rodola | set | nosy: + giampaolo.rodola |
2010-04-05 23:31:29 | michael.foord | set | nosy: + michael.foordmessages: + title: add a test command -> add a distutils test command |
2010-04-05 23:19:32 | tarek | create |