On Mon, Feb 27, 2012 at 12:58 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
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.
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.
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.
As written, yes, but easily changeable in the module code for your unique case.... mark
Mark Janssen wrote:
I'm not sure about *that* -- having to exactly reproduce the output of the interpreter seems kind of arcane to me. ;)
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.
Go with the Source, eh? I can live with that. :) ~Ethan~
Mark Janssen wrote:
I'm not sure about *that* -- having to exactly reproduce the output of the interpreter seems kind of arcane to me. ;)
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.
Go with the Source, eh? I can live with that. :) ~Ethan~
participants (2)
-
Ethan Furman -
Mark Janssen