On Mon, Mar 10, 2008 at 06:09:50PM +0100, Wichert Akkerman wrote:
[...the usual doctest vs unittest discussion ...]
Lack of isolation is a very convincing argument to me.
For me as well. Which is why I put my doctests into a traditional
tests/test_foo.py module like this:
# ... imports etc
On Tue, Mar 11, 2008 at 09:25:59AM -0400, Jim Fulton wrote:
I'm not sure what scaffolding you're referring to. Do you mean test set up?
Or the tools for normalizing output? For test set up, I don't think
there's any difference. I can sympathize with the skepticism with
normalizing output.
Stephan Richter wrote:
I am very happy about my tests in z3c.form. They demonstrate tests with
different audiences in mind.
Rightly so; they're excellent and make transition away from formlib easy.
\malthe
___
Zope-Dev maillist -
On Mar 13, 2008, at 12:11 AM, Paul Winkler wrote:
On Tue, Mar 11, 2008 at 09:25:59AM -0400, Jim Fulton wrote:
It is certainly straightforward enough to create isolated
doctests. For
edge cases, I do typically create separate isolated short doctests
that
deal just with that case. The
On Thursday 13 March 2008, Paul Winkler wrote:
On Tue, Mar 11, 2008 at 09:25:59AM -0400, Jim Fulton wrote:
It is certainly straightforward enough to create isolated doctests. For
edge cases, I do typically create separate isolated short doctests that
deal just with that case. The
Benji York wrote at 2008-3-11 09:03 -0400:
Dieter Maurer wrote:
Looks at the ZODB tests. They make heavy use of multiple inheritance
to compose test classes out of component test classes
Good point; the ZODB tests make a great argument for using doctest over
unittest.
After you switched to
Jim Fulton wrote at 2008-3-11 09:58 -0400:
On Mar 11, 2008, at 9:46 AM, Andreas Jung wrote:
...
You can also document your edgecase in the same way as comments
within your
unittests.
This is true in theory, but in practice, it almost never happens.
There is no guarantee that doctests will
Andreas Jung wrote at 2008-3-11 06:43 +0100:
...
This sounds like writing doctests just for sake of having doctests for all
and everything. I completely disagree with that. In complex algorithms
edgecases are often only of interest for the person implementing the code
in order for having a
David Pratt wrote at 2008-3-11 09:42 -0300:
I think your response gets to the heart of the issue. For
software to be useful, it is often more important for folks other than
the author to understand it. This can only occur with communication.
Sometimes it is the understanding of edgecases in
On Tue, Mar 11, 2008 at 09:25:59AM -0400, Jim Fulton wrote:
It is certainly straightforward enough to create isolated doctests. For
edge cases, I do typically create separate isolated short doctests that
deal just with that case. The assertion that doctests don't allow
isolation is simply
Hi Andreas. I think your response gets to the heart of the issue. For
software to be useful, it is often more important for folks other than
the author to understand it. This can only occur with communication.
Sometimes it is the understanding of edgecases in particular, that gets
lost over
I hate to add more to this discussion, but I think some folks might
have some miss-conceptions about doctests:
On Mar 10, 2008, at 12:39 PM, Tres Seaver wrote:
...
Becuase they make for poor unit tests? Using them to document the
mainline use cases for an API is one thing: using them to
--On 11. März 2008 09:42:11 -0300 David Pratt [EMAIL PROTECTED]
wrote:
Hi Andreas. I think your response gets to the heart of the issue. For
software to be useful, it is often more important for folks other than
the author to understand it. This can only occur with communication.
Sometimes
On Mar 11, 2008, at 9:46 AM, Andreas Jung wrote:
...
You can also document your edgecase in the same way as comments
within your
unittests.
This is true in theory, but in practice, it almost never happens.
There is no guarantee that doctests will contain useful text, but they
encourage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
I did a five-minute skim of the checkin but hope to look a bit more
tomorrow. Hopefully Marius, Benji, Albertas, or someone else who has
actually done work on this package will take a look and chime in.
I did have one
Previously Tres Seaver wrote:
Gary Poster wrote:
I did a five-minute skim of the checkin but hope to look a bit more
tomorrow. Hopefully Marius, Benji, Albertas, or someone else who has
actually done work on this package will take a look and chime in.
I did have one somewhat
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
I realize I have said this before, but then others keep urging the
doctests everywhere meme.
Indeed, and for that reason this can't be said enough. Doctests are
useful to create testable documentation. They are not the right tool to
create
On Mar 10, 2008, at 17:57 , Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Gary Poster wrote:
Also, some variety of doctest would be nice. Even when a package is
not using doctests, I add new tests as doctest unless there's a
really
good reason not to.
Becuase they make for poor
Previously Benji York wrote:
Wichert Akkerman wrote:
Previously Tres Seaver wrote:
I realize I have said this before, but then others keep urging the
doctests everywhere meme.
Indeed, and for that reason this can't be said enough. Doctests are
useful to create testable documentation. They
On Mon, Mar 10, 2008 at 6:09 PM, Wichert Akkerman [EMAIL PROTECTED] wrote:
The fact that something is popular does not necessarily mean it is the
right thing :)
Lack of isolation is a very convincing argument to me.
Perhaps more personal taste but I also find python unittests to be much
Wichert Akkerman wrote:
The fact that something is popular does not necessarily mean it is the
right thing :)
Very true. It does, however, mean that you have to have a convincing
argument to change popular opinion.
Lack of isolation is a very convincing argument to me.
This almost never
On Mar 10, 2008, at 12:39 PM, Tres Seaver wrote:
Gary Poster wrote:
[...]
Doctest/unittest holy war: bah. I've heard the arguments, I don't see
either side as perfect, and I've made my choice. I'm very fine with
others having different opinions and choices.
As Benji said, the
Gary Poster wrote:
Perhaps your argument, Tres, is that the effort outweighs the cost in
this particular case. That's a more reasonable argument to me. Maybe
the scaffolding will be arduous.
I can certainly get on board with that argument.. I, myself, have added
small unit tests to
Benji York wrote at 2008-3-10 13:03 -0400:
Wichert Akkerman wrote:
Indeed, and for that reason this can't be said enough. Doctests are
useful to create testable documentation. They are not the right tool to
create isolated, debuggable tests.
Not everyone agrees with this assertion. I for one
On Monday 10 March 2008, Wichert Akkerman wrote:
Indeed, and for that reason this can't be said enough. Doctests are
useful to create testable documentation. They are not the right tool to
create isolated, debuggable tests.
Huh? I totally disagree. If you cannot explain your software in words,
On Monday 10 March 2008, Martijn Pieters wrote:
I completely agree with Tres' and Wichert's statements on this. I only
use doctests where they actually would make sense as documentation,
the corner cases I always write as unit tests. The tools for dealing
with pure Python code are so much more
--On 10. März 2008 22:33:13 -0500 Stephan Richter
[EMAIL PROTECTED] wrote:
On Monday 10 March 2008, Wichert Akkerman wrote:
Indeed, and for that reason this can't be said enough. Doctests are
useful to create testable documentation. They are not the right tool to
create isolated,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
These changes sound great.
I just looked for your checkins in the checkins list. I didn't find
them. If I recall correctly, this usually happens if the committer is
not subscribed to the list and has not been blessed by
28 matches
Mail list logo
