I just realized I've been replying personally to these replies instead
of the whole list (damn I hate that!). So resending a bunch of
messages that went to individuals. [Mark]
On Fri, Feb 17, 2012 at 3:12 PM, Nick Coghlan
On Sat, Feb 18, 2012 at 7:57 AM, Mark Janssen
wrote: Anyway... of course patches welcome, yes... ;^)
Not really. doctest is for *testing code example in docs*.
I understand. This is exactly what I was wanting to use it for. As Tim says "literate testing" or "executable documentation". The suggestions I made are for enhancing those two. Personally, I don't find unittest very suitable for test-driven *development*, although it *is* obviously well-suited for writing assurance tests otherwise. The key difference, to me, is in that doctest promotes tests being written in order to have the *additional functionality* of documentation. That makes it fun since your getting "twice the value for the cost of one", and that alone is the major item which drives test-driven development (IMHO) within the spirit of python, otherwise unittest is rather bulky to write in and of itself. Does anyone really use unittest outside the context of shop policy? mark
Mark Janssen wrote:
On Fri, Feb 17, 2012 at 3:12 PM, Nick Coghlan wrote:
On Sat, Feb 18, 2012 at 7:57 AM, Mark Janssen wrote:
Anyway... of course patches welcome, yes... ;^) Not really. doctest is for *testing code example in docs*.
I understand. This is exactly what I was wanting to use it for. As Tim says "literate testing" or "executable documentation".
The suggestions I made are for enhancing those two.
Personally, I don't find unittest very suitable for test-driven *development*, although it *is* obviously well-suited for writing assurance tests otherwise.
I like unittest for TDD.
The key difference, to me, is in that doctest promotes tests being written in order to have the *additional functionality* of documentation. That makes it fun since your getting "twice the value for the cost of one", and that alone is the major item which drives test-driven development (IMHO) within the spirit of python, otherwise unittest is rather bulky to write in and of itself.
unittest can be a bit bulky, but definitely worth it IMO, especially when covering the corner cases. I have not used doctest, but I can say that I strongly dislike having more than one or two examples in a docstring. Having all possibilities (including corner cases) in a separate file I am okay with (as that would be documentation -- when I'm reading code I want to see code, and I'll look up the docs if I have a question). The other gripe I have (possibly easily fixed): my python prompt is '-->' (makes email posting easier) -- should my doctests still use '>>>'? Will doctest fail on my machine?
Does anyone really use unittest outside the context of shop policy?
Yup.
On 2/27/2012 2:23 PM, Mark Janssen wrote:
I just realized I've been replying personally to these replies instead of the whole list (damn I hate that!). So resending a bunch of messages that went to individuals. [Mark] On Fri, Feb 17, 2012 at 3:12 PM, Nick Coghlan
wrote: On Sat, Feb 18, 2012 at 7:57 AM, Mark Janssen
wrote: Anyway... of course patches welcome, yes... ;^) Not really. doctest is for *testing code example in docs*. I understand. This is exactly what I was wanting to use it for. As Tim says "literate testing" or "executable documentation". I think you misunderstand: Nick meant, "doctest is only useful for testing the snippets of code that naturally appear in documentation meant for people to read." Many people agree with this sentiment, and find doctest unsuitable for writing comprehensive tests. The suggestions I made are for enhancing those two.
Personally, I don't find unittest very suitable for test-driven *development*, although it *is* obviously well-suited for writing assurance tests otherwise.
The key difference, to me, is in that doctest promotes tests being written in order to have the *additional functionality* of documentation. That makes it fun since your getting "twice the value for the cost of one", and that alone is the major item which drives test-driven development (IMHO) within the spirit of python, otherwise unittest is rather bulky to write in and of itself.
Does anyone really use unittest outside the context of shop policy? Many, many people use unittest, namely, all of us that think doctest is a cute idea, but its many limitations hobble it for serious work.
mark _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Mark Janssen
The key difference, to me, is in that doctest promotes tests being written in order to have the *additional functionality* of documentation.
I think that doctest promotes docstrings being written with the additional functionality of tests. To that extent, it is very good. -- \ “The fact that I have no remedy for all the sorrows of the | `\ world is no reason for my accepting yours. It simply supports | _o__) the strong probability that yours is a fake.” —Henry L. Mencken | Ben Finney
participants (4)
-
Ben Finney
-
Ethan Furman
-
Mark Janssen
-
Ned Batchelder