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
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
> 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.