dreamingforward at gmail.com
Mon Feb 27 20:26:23 CET 2012
On Fri, Feb 17, 2012 at 9:50 PM, Steven D'Aprano <steve at 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...)
More information about the Python-ideas