[Distutils] RFC: Standard Declaration of tests in eggs

[Jim Fulton]

Phillip J. Eby wrote:
...
>> Why can't an entry point invoke a test loader itself?
>> This seems much simpler and more straightforward to me.
> 
> Because that requires you to write code for something that can 
> adequately be expressed through an existing configuration mechanism.  
> *And* you have to write that code in every project.

It's probably a couple of lines. Import a loader and call it.
That doesn't seem like a big deal to me. Nice and explicit too.
Besides, I expect most projects will have a single test suite
(function) that could just be named directly.

> If you're using setuptools' ScanningLoader (which is the default for the 
> "test" command, and which I believe should be the default for this 
> proposal as well), you automatically get all TestCase subclasses in all 
> submodules of the package you target, and if any module has an 
> 'additional_tests()' function, it's called to get a suite that's added 
> in.  This lets you just make your entry point a "whatever.tests" 
> package, without writing any extra code (unless you want to throw in 
> some doctests via a few 'additional_tests()' functions).
> 
> See the setuptools documentation for the 'test_suite' and 'test_loader' 
> arguments to setup() for the full details.

I've looked at this and it is a bit too magic for my taste.
It's also a heck of a lot to get one's head around.
(This is true of setuptools in general.)
Of course, it doesn't help much with our doctests
and for our older unittest tests, we have lots of TestCase
subclasses that aren't meant to be run directly, but are base
classes for other TestCase classes. It appears that your loader would
pick these up incorrectly.

Of course, we have our own loader (of sorts) and it has it's
own magic conventions.  We would likely use that for our larger projects
(e.g. ZODB) that have more than a few test suites.  Importing some
function and invoking it explicitly will not be the least bit onerous
for those projects.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org