[Python-ideas] Builtin test function

[spir]

Le Fri, 27 Mar 2009 19:33:49 -0700,
average <dreamingforward at gmail.com> s'exprima ainsi:

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

Really true for me.
Also, I think python needs a standard method for testing. As well as for doc-ing.
[But I'm not sure that pseudo-strings are the best format to store test information (idem for doc). I would prefere specialized types -- maybe subtype of string.]
I really support the idea because I feel personally concerned: would probably do a more systematical use of tests if there were a (well thought / straightforward / *clear*) builtin standard.

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

The analogy with help() sounds sensible.
A builtin/standard testing func should definitely be called test(). *Other* test methods should use another name or be prefixed with a module name.
Now, we must also cope with existing code. The name should not imply that it's a special method. Maybe runtest() or check()?

> Personally, I'm +2 on the idea, but that may only be in cents....
> 
> marcos

Denis
------
la vita e estrany