doctest, unittest, or if __name__='__main__'

[john_sips_tea@yahoo.com]

For writing testcode, it looks like there's three ways that it's
typically done:

(1). using the doctest module,

(2). using the unittest module (i.e. "pyunit"), or else

(3). just putting an "if __name__ = '__main__':" at the bottom of your
module containing code to manually run your class through its paces.

So, which way is preferred? Seems to me that unittest is the way to go,
at least because it has you separate your test code from the code being
tested.

If unittest is the standard way to write test code, why do we still
have doctest? (I notice there's no mention in PEP 3000 of deprecating
the doctest module).

[Fredrik Lundh]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com wrote
[color=blue]
> For writing testcode, it looks like there's three ways that it's
> typically done:
>
> (1). using the doctest module,
>
> (2). using the unittest module (i.e. "pyunit"), or else
>
> (3). just putting an "if __name__ = '__main__':" at the bottom of your
> module containing code to manually run your class through its paces.
>
> So, which way is preferred? Seems to me that unittest is the way to go,
> at least because it has you separate your test code from the code being
> tested.
>
> If unittest is the standard way to write test code, why do we still
> have doctest?[/color]

because it's a vastly superior way to write tests ?
[color=blue]
> (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).[/color]

why is it that comp.lang.pytho n is suddenly full of folks who
want to deprecate anything they don't understand ? don't
you have better things to do with your time ?

</F>

[Christoph Zwerschke]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com wrote:[color=blue]
> If unittest is the standard way to write test code, why do we still
> have doctest? (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).[/color]

Because both have their pros and cons and their right to exist. Doctest
is really easy to use and you can kill two birds with one stone.

Rather than removing one of the two, I would like to see yet another
alternatise such as py.test in the standard lib, because unittest is
indeed standard, but clumsy and un-pythonic.

-- Christoph

[john_sips_tea@yahoo.com]

Re: doctest, unittest, or if __name__='__mai n__'

> because it's a vastly superior way to write tests ?

Well, since this is a mailing list where this sort of thing is
discussed, and since I was was asking about which way
is preferred, could you tell us why you (presumably) think
doctest is vastly superior to unittest?
[color=blue]
> why is it that comp.lang.pytho n is suddenly full of folks who
> want to deprecate anything they don't understand ?[/color]

I didn't say I wanted to deprecate it. I wrote that I noticed
there was no mention in PEP 3k about deprecating it.
[color=blue]
> don't you have better things to do with your time ?[/color]

That wasn't very friendly.

Anyhow, I'm not attacking doctest, but rather, just trying
to understand why there seems to be two very similar ways
of testing your code built into the system (considering that
one motto around here is "There should be one -- and
preferably only one -- obvious way to do it.").

[Bruno Desthuilliers]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com a écrit :[color=blue]
> For writing testcode, it looks like there's three ways that it's
> typically done:[/color]

Actually, there's at least one more
[color=blue]
> (1). using the doctest module,
>
> (2). using the unittest module (i.e. "pyunit"), or else
>
> (3). just putting an "if __name__ = '__main__':" at the bottom of your
> module containing code to manually run your class through its paces.[/color]

(4) using pytest
[color=blue]
> So, which way is preferred? Seems to me that unittest is the way to go,
> at least because it has you separate your test code from the code being
> tested.[/color]

Which may or may not be such a good thing... I prefer to have my tests
with the code they're testing.
[color=blue]
> If unittest is the standard way to write test code, why do we still
> have doctest?[/color]

Because doctest is simple, great, and definitively more pythonic than
unittest ?
[color=blue]
> (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).
>[/color]
Hopefully not.

[john_sips_tea@yahoo.com]

Re: doctest, unittest, or if __name__='__mai n__'

> and you can kill two birds with one stone.

By that, do you mean you can write your tests and your
docstrings in one shot with doctest?
[color=blue]
> I would like to see yet another alternatise such as py.test
> in the standard lib,[/color]

Ah: http://codespeak.net/py/current/doc/home.html

[Tim Peters]

Re: doctest, unittest, or if __name__='__mai n__'

[john_sips_tea@y ahoo.com <john_sips_tea@ yahoo.com>[[color=blue]
> For writing testcode, it looks like there's three ways that it's
> typically done:
>
> (1). using the doctest module,
>
> (2). using the unittest module (i.e. "pyunit"), or else
>
> (3). just putting an "if __name__ = '__main__':" at the bottom of your
> module containing code to manually run your class through its paces.
>
> So, which way is preferred?[/color]

Serious testers often use both #1 and #2, depending on the specific
test at hand. #3 doesn't work well in practice.
[color=blue]
> Seems to me that unittest is the way to go, at least because it has
> you separate your test code from the code being tested.[/color]

Equally true of #1, if you write doctest files separate from your
code. I suggest you look at Zope3, which is a major project using
that style extensively. In fact, it's standard practice there to
write "tutorial doctest" files for a new feature before writing code
to implement it. The text serves as a tutorial introduction to the
feature, and the tests scattered throughout clarify, illustrate, and
verify the text's claims. By writing the text in ReST format, these
doctest files also serve as the source for auto-generated
documentation in HTML format (available interactively from a Zope3
console). This combination of virtues has proved extremely
productive.

BTW, doctest makes it a little easier to write prose than to write
Python code, and your typical frazzled programmer is highly influenced
by small biases ;-) The reverse is true of raw unittest, which goes a
long way toward explaining why you see so many unittests in real life
that are incomprehensibl e: when it's easier to write code than
explanations, that's what people do.
[color=blue]
> If unittest is the standard way to write test code, why do we still
> have doctest?[/color]

Because doctest is much better for some kinds of testing. See above.
[color=blue]
> (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).[/color]

Or of deprecating the unittest module ;-)

[Christoph Zwerschke]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com schrieb:[color=blue]
> Anyhow, I'm not attacking doctest, but rather, just trying
> to understand why there seems to be two very similar ways
> of testing your code built into the system (considering that
> one motto around here is "There should be one -- and
> preferably only one -- obvious way to do it.").[/color]

I don't think doctest and unittest are similar ways; they are pretty
different ways. Also, the "one obvious way" should not be overstressed
and taken as a dogma for libraries, modules and frameworks. Actually, on
that level we see the opposite in the Python world: A plethora of tools
for XML processing, GUI frameworks, Web frameworks etc. Some think this
is deplorable, but I see this as something exciting and positive.

-- Christoph

[Christoph Zwerschke]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com wrote:[color=blue]
> By that, do you mean you can write your tests and your
> docstrings in one shot with doctest?[/color]

Right. The tests serve also as usage examples.

[Terry Hancock]

Re: doctest, unittest, or if __name__='__mai n__'

On Tue, 21 Mar 2006 22:26:57 +0100
Christoph Zwerschke <cito@online.de > wrote:[color=blue]
> john_sips_tea@y ahoo.com wrote:[color=green]
> > If unittest is the standard way to write test code, why
> > do we still have doctest? (I notice there's no mention
> > in PEP 3000 of deprecating the doctest module).[/color]
>
> Because both have their pros and cons and their right to
> exist. Doctest is really easy to use and you can kill two
> birds with one stone.
>
> Rather than removing one of the two, I would like to see
> yet another alternatise such as py.test in the standard
> lib, because unittest is indeed standard, but clumsy and
> un-pythonic.[/color]

e.g....
Doctest is very easy to use, so it's easy to ensure that
tests get written. OTOH, they're only really good for stuff
that can be easily tested in the interpreter (e.g. that can
be easily verified from their text output). When you get
into stickier stuff like graphics and web programming, the
formal structure of pyunit can be easier to adapt than
something which is intrinsically based on string processing.

Haven't seen py.test before, but I'm looking now -- thanks
for the link. :-)

Cheers,
Terry

--
Terry Hancock (hancock@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Fredrik Lundh]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com wrote:
[color=blue]
> Well, since this is a mailing list where this sort of thing is
> discussed, and since I was was asking about which way
> is preferred, could you tell us why you (presumably) think
> doctest is vastly superior to unittest?[/color]

doctest comes with extensive documentation, which, among other
things, discuss the advantages of using doctest. have you read the
documentation ?

http://www.python.org/doc/lib/module-doctest.html

[color=blue][color=green]
> > don't you have better things to do with your time ?[/color]
>
> That wasn't very friendly.[/color]

so you think that a "why all this creativity when you could just
standardize on something ported from java, and throw away every-
thing else" post is friendly ? really ?
[color=blue]
> Anyhow, I'm not attacking doctest, but rather, just trying
> to understand why there seems to be two very similar ways
> of testing your code built into the system (considering that
> one motto around here is "There should be one -- and
> preferably only one -- obvious way to do it.").[/color]

if you think that motto means that there should be only one non-
deprecated solution to any higher-level problem, you've completely
and utterly missed the point.

</F>

[Fredrik Lundh]

Re: doctest, unittest, or if __name__='__mai n__'

Terry Hancock wrote:
[color=blue]
> Doctest is very easy to use, so it's easy to ensure that
> tests get written. OTOH, they're only really good for stuff
> that can be easily tested in the interpreter (e.g. that can
> be easily verified from their text output). When you get
> into stickier stuff like graphics and web programming, the
> formal structure of pyunit can be easier to adapt than
> something which is intrinsically based on string processing.[/color]

that's puzzling. I do lots of graphics, and some web programming (my
company's main product is a web application server for graphics), and
we use doctest for everything.

I find it a bit odd that someone thinks that there are tests for which

assert something == somevalue

is easier to write than either
[color=blue][color=green][color=darkred]
>>> something[/color][/color][/color]
somevalue

or
[color=blue][color=green][color=darkred]
>>> something == somevalue[/color][/color][/color]
True

</F>

[Fredrik Lundh]

Re: doctest, unittest, or if __name__='__mai n__'

Tim Peters wrote:
[color=blue]
> Equally true of #1, if you write doctest files separate from your
> code.[/color]

newer versions of doctest have more extensive support for this, but the old
trick of using doctest to test your *test programs* work remarkably well.
[color=blue]
> In fact, it's standard practice there to write "tutorial doctest" files for a
> new feature before writing code to implement it.[/color]

another good practice is to add regression doctests for each verified bug,
*before* attempting to fix it.

</F>

[Max M]

Re: doctest, unittest, or if __name__='__mai n__'

john_sips_tea@y ahoo.com wrote:[color=blue][color=green]
>>and you can kill two birds with one stone.[/color]
>
>
> By that, do you mean you can write your tests and your
> docstrings in one shot with doctest?[/color]


Exactly.

[color=blue][color=green][color=darkred]
>>> '\n'.join(['Doctests are absolutely brilliant!'] * 100)[/color][/color][/color]


They combine two brilliant ideas that are hard to do in practice.
"Testing" and "Literate Programming"

In the process it even manages to make both a lot easier.


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/

IT's Mad Science

Phone: +45 66 11 84 94
Mobile: +45 29 93 42 96

[john_sips_tea@yahoo.com]

Re: doctest, unittest, or if __name__='__mai n__'

> so you think that a "why all this creativity when you could just[color=blue]
> standardize on something ported from java, and throw away every-
> thing else" post is friendly ? really ?[/color]

Sorry for the sloppy writing. Thanks for clarifying. I wrote:
[color=blue]
> If unittest is the standard way to write test code, why do we still
> have doctest? (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).[/color]

when that should've been
[color=blue]
> If one is the standard way to write test code, why do we still
> have the other one? (I notice there's no mention in PEP 3000 of
> deprecating either module).[/color]

Also, as an aside, I don't think there's anything inherently wrong
with porting something from Java (or Smalltalk, or any other
language). Such ported software may or may not be a good fit
for Python.