[Python-ideas] Location of tests for packages

Ron Adam rrr at ronadam.com
Tue Jan 25 04:38:17 CET 2011

Moving these suggestions to python ideas as they are not immediately 
relevant to the current python dev discussion at this time. ;-)

I'm really just wondering what others think, is this something worth 
working on?

On 01/24/2011 01:46 PM, Raymond Hettinger wrote:
> Right now, the tests for the unittest package are under the package
> directory instead of Lib/test where we have most of the other tests.
> There are some other packages that do the same thing, each for their own
> reason.
> I think we should develop a strong preference for tests going under
> Lib/test unless there is a very compelling reason.

> * For regrtest to work, there still needs to be some file in Lib/test
> that dispatches to the alternate test directory.

Currently tests are mostly separate from the modules.  Mostly separate 
because, some modules have doctests in them, and/or a test() function to 
run tests.  But the test function name isn't special in any way as far as I 
know.  It's usually _test(), but it could be something else.

Would it help things to have a special __test__ name?  ie... special to 
python, in that module.__test__() can be depended on to run the tests for 
that module? (or package)

I've found it useful to add a -T option to my own python applications to 
run tests.  But moving it from being a module option to a python option, 
would make that even nicer. Where python -T modulename called the 
__test__() function. (or evoke the tests in another way.)

With a dependable way to evoke the tests no matter where they are located, 
it then becomes just a matter of iterating the list of modules in the 
library (or a directory) to run all the tests.

But then, what's the  best way to actually do that?

The current method uses pattern matching ... (not my first choice for sure)

python -m unittest discover -s project_directory -p '*_test.py'
python -m unittest discover project_directory '*_test.py'

Those lines are way too long in my opinion.

In the above, the test functions need to begin with an underscore.  I'm not 
sure the discoverable test function should be private,  The very act of 
finding them suggests they should be a public, but special API, rather than 
a private API to me.  If they were only accessed from inside the module or 
package they are in, then being private makes sense.

One choice is that __test__ is special to doctest and unittest only.

python -m unittest module    # runs module.__test__() if it exists.

Or a little more far out ...

The __test__() function could be called with "python -T module".  But then 
it seems that maybe we could also have a __main__() function be called with 
"python -M module".  (?)

Alternately ...  "python -T module" could alter the name of the module.

if __name__ == "__main__":

elif __name__ == "__test__":
    _test()                     # a private name is ok here.



More information about the Python-ideas mailing list