On Mon, Feb 27, 2012 at 12:58 PM, Ethan Furman ethan@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.
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.
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....
mark
Mark Janssen wrote:
On Mon, Feb 27, 2012 at 12:58 PM, Ethan Furman ethan@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~
Mark Janssen wrote:
On Mon, Feb 27, 2012 at 12:58 PM, Ethan Furman wrote:
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....
Which means my doctests will then fail on other's machines unless they also change their local module and their python prompt. Not good.
~Ethan~
-
Ethan Furman -
Mark Janssen