On Fri, Feb 17, 2012 at 9:50 PM, Steven D'Aprano <steve@pearwood.info> wrote:

Really? Not in my experience, although I admit I haven't tried to push the envelope too far.

But I haven't had any problem with a literate programming model:

* Use short, self-contained but not necessarily exhaustive examples in the code's docstrings (I don't try to give examples of *every* combination of good and bad data, special cases, etc. in the docstring).

* Write extensive (ideally exhaustive) examples with explanatory text, in a separate text file.

Hmmm, interesting.  I generally like to keep it all in one file and define a dummy "test" function that just contains doctest code so that it can be all kept in one file and in-sync.

If my tests require setting up and tearing down resources, I stick to unittest which has better setup/teardown support. (It would be hard to have *less* support for setup and teardown than doctest.)

If doctest had context-scoping, I think it would be superior to unittest.  SetUp functionality would be contained in the class definition's __doc__, or out in the module's own __doc__.  If any teardown functionality was necessary in the class's code a dummy teardown method could be defined at the end of the class definition. (Not as ideal as a more integrated test-driven development approach, but likely acceptable...) mark