doctest, unittest, or if __name__='__main__'
john_s...@yahoo.com
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
> 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?
because it's a vastly superior way to write tests ?
> (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).
why is it that comp.lang.python 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
> 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).
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_s...@yahoo.com
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?
> why is it that comp.lang.python is suddenly full of folks who
> want to deprecate anything they don't understand ?
I didn't say I wanted to deprecate it. I wrote that I noticed
there was no mention in PEP 3k about deprecating it.
> don't you have better things to do with your time ?
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.").
Jay Parlar
On Mar 21, 2006, at 1:12 PM, Fredrik wrote:
>
>> (I notice there's no mention in PEP 3000 of deprecating
>> the doctest module).
>
> why is it that comp.lang.python 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 ?
I've wondered the same sort of thing for awhile. It often comes back to
people taking ideas from whatever language they're familiar with, and
trying to force them into Python.
The reason for this, as I see it, is that Python is so incredibly easy
to get into, that many people think they fully understand it after a
few days use.
Jay P.
Bruno Desthuilliers
> For writing testcode, it looks like there's three ways that it's
> typically done:
Actually, there's at least one more
> (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.
(4) using pytest
> 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.
Which may or may not be such a good thing... I prefer to have my tests
with the code they're testing.
> If unittest is the standard way to write test code, why do we still
> have doctest?
Because doctest is simple, great, and definitively more pythonic than
unittest ?
> (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).
>
Hopefully not.
john_s...@yahoo.com
By that, do you mean you can write your tests and your
docstrings in one shot with doctest?
> I would like to see yet another alternatise such as py.test
> in the standard lib,
Tim Peters
> 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?
Serious testers often use both #1 and #2, depending on the specific
test at hand. #3 doesn't work well in practice.
> 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.
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 incomprehensible: when it's easier to write code than
explanations, that's what people do.
> If unittest is the standard way to write test code, why do we still
> have doctest?
Because doctest is much better for some kinds of testing. See above.
> (I notice there's no mention in PEP 3000 of deprecating
> the doctest module).
Or of deprecating the unittest module ;-)
Christoph Zwerschke
> 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.").
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
> By that, do you mean you can write your tests and your
> docstrings in one shot with doctest?
Right. The tests serve also as usage examples.
Terry Hancock
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 (han...@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Fredrik Lundh
> 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?
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
> > don't you have better things to do with your time ?
>
> That wasn't very friendly.
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 ?
> 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.").
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
> 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.
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
>>> something
somevalue
or
>>> something == somevalue
True
</F>
Fredrik Lundh
> Equally true of #1, if you write doctest files separate from your
> code.
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.
> In fact, it's standard practice there to write "tutorial doctest" files for a
> new feature before writing code to implement it.
another good practice is to add regression doctests for each verified bug,
*before* attempting to fix it.
</F>
Max M
>>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?
Exactly.
>>> '\n'.join(['Doctests are absolutely brilliant!'] * 100)
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_s...@yahoo.com
> standardize on something ported from java, and throw away every-
> thing else" post is friendly ? really ?
Sorry for the sloppy writing. Thanks for clarifying. I wrote:
> 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).
when that should've been
> 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).
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.
Marc 'BlackJack' Rintsch
wrote:
I see it this way: `unittest` is for testing code and `doctest` is for
testing examples in docstrings. If you put all your tests in the
docstrings there will be much code that's quite irrelevant for documenting
the function/method/class.
Testing real examples in doctstrings, or external documentation like
tutorials, is important because it's very frustrating for people reading
the docs if the examples don't work as advertised.
Ciao,
Marc 'BlackJack' Rintsch
Fredrik Lundh
> I see it this way: `unittest` is for testing code and `doctest` is for
> testing examples in docstrings. If you put all your tests in the
> docstrings there will be much code that's quite irrelevant for documenting
> the function/method/class.
so put the tests in your test program instead, and use doctest to make
sure that the test program works as advertised.
(or use doctest on separate test scenario documents)
if you prefer the doctest approach, there's no reason to use unittest for
anything.
</F>
lollipo...@gmail.com
could quickly summarize the ways in which unittest is unpythonic, or
point me to somewhere which discusses this.
Is this 'consensus opinion' or mainly your own opinion?
Is there a summary somewhere (in addition to the Zen of Python thingy)
of what kinds of things are 'pythonic' and why they are considered so?
I see it referred to a lot, and am starting to get a feel for it in
some areas but not others.
I am fairly newbie-ish, having been actively working as a python
programmer for the last 6 months, although I did first learn the basics
several years ago.
I have noticed some distinctly funny and confused feelings I get when
using the unittest module, stuff that feels clunky and odd about how it
is set-up, however I thought that this was just due to *my personal*
lack of understanding of the deep magic and sophisticated design
patterns used in this module!
If it turns out to be 'unpythonic' then I can blame the funny feelings
on that and sigh in a smug and vaguely superior way whenever I get them
;)
I have not yet used the doctest module but would like to begin soon :)
I am also very interested in py.lib, just looked at the website and
will be keeping an eye on it.
One of the things I am doing a lot of at the moment is documentation
and testing, hence the interest!
Wendy Langer
Benji York
> 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.
As pointed out earlier in this thread, Zope 3 has embraced doctests in a
big way (and they've paid off in a big way too). Obviously we test lots
of web apps and had to come up with something to allow us to do decent
doctests of them. Unsurprisingly it's documented with a doctest:
http://svn.zope.org/*checkout*/Zope3/trunk/src/zope/testbrowser/README.txt
--
Benji York
Paul Rubin
> I have noticed some distinctly funny and confused feelings I get when
> using the unittest module, stuff that feels clunky and odd about how it
> is set-up, however I thought that this was just due to *my personal*
> lack of understanding of the deep magic and sophisticated design
> patterns used in this module!
>
> If it turns out to be 'unpythonic'
The unpythonicness stems from it being basically a reimplementation of
JUnit, which was designed for use with Java.
Roy Smith
JUnit, in turn, is based on a package first implemented in SmallTalk
(http://www.xprogramming.com/testfram.htm).
On stuff like this, I'm not opposed to things being slightly unpythonic.
PyUnit does have some clunkyness to it, but there is some value in having
all the unit test frameworks have a similar feel across languages.
Unfortunately, it has become fashionable to call any sort of unit test
framework "xxxUnit", whether or not it resembles the original or not.
sk...@pobox.com
Paul> The unpythonicness stems from it being basically a
Paul> reimplementation of JUnit, which was designed for use with Java.
I think there are a few modules in Python which suffer that affliction.
Skip
Christoph Zwerschke
> Hi there Christopher, I was wondering if you (or anyone reading this )
> could quickly summarize the ways in which unittest is unpythonic, or
> point me to somewhere which discusses this.
> Is this 'consensus opinion' or mainly your own opinion?
It is just a consequence from the fact that unittest is actually a port
from JUnit (Java) to Python, i.e. a consequence of trying to emulate a
standard framework that many programmers are already familiar with,
which is essentially not a bad idea. However, if you try to counterfeit
Java programming, your code won't be effective or elegant in Python.
> Is there a summary somewhere (in addition to the Zen of Python thingy)
> of what kinds of things are 'pythonic' and why they are considered so?
> I see it referred to a lot, and am starting to get a feel for it in
> some areas but not others.
It's probably never been listed completely (and it also changes slowly
as the language evolves). Programming in an unpythonic way is like
driving a nail with a screwdriver. Here are some more explanations:
http://faassen.n--tree.net/blog/view/weblog/2005/08/06/0
http://mail.python.org/pipermail/europython/2005-April/004975.html
-- Christoph
Fredrik Lundh
> > Is this 'consensus opinion' or mainly your own opinion?
>
> It is just a consequence from the fact that unittest is actually a port
> from JUnit (Java) to Python, i.e. a consequence of trying to emulate a
> standard framework that many programmers are already familiar with,
> which is essentially not a bad idea. However, if you try to counterfeit
> Java programming, your code won't be effective or elegant in Python.
comparing unittest to py.test (which is from the "almost too clever"
school of pythonic engineering) might be illustrative:
http://ianbicking.org/docs/pytest-presentation/pytest-slides.html
(see the "why not unittest" slide for a list of issues with unittest)
> > Is there a summary somewhere (in addition to the Zen of Python thingy)
> > of what kinds of things are 'pythonic' and why they are considered so?
> > I see it referred to a lot, and am starting to get a feel for it in
> > some areas but not others.
>
> It's probably never been listed completely (and it also changes slowly
> as the language evolves).
it cannot be defined, per definition. a good approxmation is "pencil-like
qualities".
</F>
Ben Finney
> http://ianbicking.org/docs/pytest-presentation/pytest-slides.html
> (see the "why not unittest" slide for a list of issues with
> unittest)
To see many of these points rebutted, see this post:
<URL:http://dirtsimple.org/2005/08/ruby-gems-python-eggs-and-beauty-of.html>
including the comments between PJE (the post author), Ian (py.test),
and Ori (TestOOB).
--
\ "Laugh and the world laughs with you; snore and you sleep |
`\ alone." -- Anonymous |
_o__) |
Ben Finney