(resent to mailinglist because of mailer errors) Steven Knight wrote:

...

Instead of discussing what the "right" way to do testing really is, why not simply leave this decision to the package author and only ask for an entry point, e.g.

setup(... tests = [ TestSuite('mytests', run=myunittests.run, verbose=1), TestSuite('moretests', run=mymodule._test) ], ...)

The only question I see coming up is whether to run tests automatically or only at request.

Hear, hear. There are too many different testing methodologies to try to pick the "right" one for distutils to support. Within my project alone (SCons) we use two separate testing methodologies, PyUnit for per-module unit tests and a TestCmd.py module for end-to-end command testing. Anything more restrictive than a simple, generic "run the tests" interface would be a problem.

One likes PyUnit, one doesn't, one likes doctest, one doesn't... Tests can be done for two logical units: For the package as whole and per module: - So we should have a "test" attribute to each extension and py_module defined in setup.py, which provides a customized test routine. - and there should be the test command that looks a a global variable for customized tests or tries to call the test method for each module. Sorry, I can't provide code, I am just new to PyUnit and to distutils. This is the reason why I asked this list. Thank you for that amazing echo. This is the reason, why I call attention to the need of using standard utilities - PyUnit seems to me a standard or default for testing. Imo doctest intends to test documentation and reference example code and not "boring" test routines. But once more: Thanks and a fast solution.

[Achim Gaedke]

Imo doctest intends to test documentation and reference example code and not "boring" test routines.

[Andrew Kuchling]

Not at all; there are people who use primarily doctest,

You're both right. doctest (and I should know <wink>) was indeed *intended* to verify examples in docstrings, and that's all. The only major feature I ever added was Christian Tismer's suggestion to add a magical __test__ dict, and that turned out to be a powerful hook allowing to build all sorts of frameworks on top. However, I have so far refused to do the latter: the unittest framework drives me mad with frustration (people layer test classes is such convoluted ways you can't follow the logic anymore, and the business of not showing *any* info beyond "ERROR" for unexpected exceptions until the end of the whole run has wasted countless hours of my time). But I don't have a better framework in mind, so screw it <wink>.

and I use a completely different unit test module that isn't included with Python at all.

Chicken.