On 11 Dec 2006 00:27:28 -0800, "Ravi Teja" <[EMAIL PROTECTED]> tried to
confuse everyone with this message:
>
>That's a lot of hate in 2 sentences for judging a novel feature you
>barely came across.
>
But, you have to admit that it looks horrible (at least at the first glance). If
there's some programming style that I absolutely can't stand, it would be the
one where programmer writes a huge block of commentary describing what a
function does, followed by one-liner of code, which contains the same amount of
information in itself. With doctest it is even worse, because examples also
contain superfluous information. Everyone can just copy-paste the code in REPL
and see what happens when you execute it. Besides that, there are many reasons
why tests should be stored in a separate file, or at least not in the same
function that they are testing.
Also Wikipedia article contains some "Cons of doctest" that look pretty nasty:
* Large numbers of tests in a docstring can become unwieldy. docstrings
should be pruned and excised tests put in external file(s).
* Tests producing large amounts of output make for large docstrings.
* Debugging integration is far from perfect
* 'print' (or 'trace') debugging is not possible (because it intervenes with
the test result)
* Test setup has to be either copied or hidden away from the test, making
the overall environment harder to understand.
* Many of the complex assertions of existing unit tests frameworks do not
exist, (e.g. assertRaises, assertEquals, assertAlmostEqual, ...), although some
are not necessary.
* Failing assertions are very hard to debug (Especially in Web applications
if the expected result is a web page with a lot of HTML)
It's not surprising that no one uses this stuff for serious work.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
--
http://mail.python.org/mailman/listinfo/python-list
