[Python-ideas] Fwd: doctest

[Ethan Furman]

Mark Janssen wrote:
> On Mon, Feb 27, 2012 at 12:58 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> Mark Janssen wrote:
>>> 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.
> 
> I should probably correct myself.  It is suiltable, just not
> enjoyable.  But now I know you are someone who likes all that arcana
> of unittest module.

I'm not sure about *that* -- having to exactly reproduce the output of 
the interpreter seems kind of arcane to me.  ;)


>> unittest can be a bit bulky, but definitely worth it IMO, especially when
>> covering the corner cases.
> 
> Corner cases are generally useful for the developer to know about, so
> its worth it to mention (==> test) in the documentation.

Absolutely.  I can see great value to using doctest on documentation, 
and even on code itself -- as I mentioned already, I just hate having 
code cluttered with lots of non-code.

The other thing I like about unittest as opposed to doctest is the 
ability to be exhaustive.  For an example, take a look at the tests I 
have for my dbf module on PyPI -- not even sure how I could convert that 
into a doctest format.

>> I have not used doctest, but I can say that I strongly dislike having more
>> than one or two examples in a docstring.
> 
> This is often just a failure to separate tests property among different methods.
> 
>> 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?
> 
> As written, yes, but easily changeable in the module code for your
> unique case....

Go with the Source, eh?  I can live with that.  :)

~Ethan~