Builtin test function
There's been some discussion about automatic test discovery lately. Here's a random (not in any way thought through) idea: add a builtin function test() that runs tests associated with a given function, class, module, or object.
Improved testing is always welcome, but why a built-in?
I know testing is important, but is it so common and important that we need it at our fingertips, so to speak, and can't even import a module first before running tests? What's the benefit to making it a built-in instead of part of a test module?
The advantage would be a uniform and very simple interface for testing any module, without having to know whether I should import doctest, unittest or something else (and having to remember the commands used by each framework). It would certainly not be a replacement for more advanced test frameworks.
By making it a builtin it's also pointing out to users that code-testing is an important part of the python culture (as well as good development practice). It may seem easy "just to do a module import and then run the imported test function", but such a construct says that testing is just an optional thing among many dozens of modules within python. As for a name, Guido's criticism aside, I do like like it spelled test() with usage very much similar to the builtin help() function--both would be accessing the same docstrings but for two different purposes. I think it would add a lot of encouragement for the use of doctest (one of my favorites) as well as facilitate good test-driven development. And, regarding the name, if any function deserves the name test() it would be this builtin--all others would necessarily be secondary. But if there's rancor regarding the name, call it testdoc() or something. Personally, I'm +2 on the idea, but that may only be in cents.... marcos PS. Add test() to the GSoC suggesting of improving doctest with scope-aware doc-test variables (for easing setup code between module->class->method docs).
participants (2)
-
average
-
spir