Le Fri, 27 Mar 2009 19:33:49 -0700, average <dreamingforward@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

Le Fri, 27 Mar 2009 19:33:49 -0700, average <dreamingforward@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