Home Original page

[Python-ideas] doctest

Mark Janssen dreamingforward at gmail.com
Mon Feb 27 20:25:53 CET 2012 
On Fri, Feb 17, 2012 at 9:23 PM, Ian Bicking <ianbicking at gmail.com> wrote:
> On Feb 17, 2012 3:58 PM, "Mark Janssen" <dreamingforward at gmail.com> wrote:
>> Without #1, "literate testing" becomes awash with re-defining re-used
>> variables which, generally, also detracts from exact purpose of the
>> test -- this creates testdoc noise and the docs become less useful.
>
> I dunno... I find the discipline of defining your prerequesites to be a
> helpful feature of doctest (I find TestCase.setUp to be smelly).

Yeah, I kinda agree, but in this case the doctests are always confined
to the same module (or class) and have a standardized location, so
always near at hand (at least if you're using them well) if you want
to see what a variable used in a sub-test has been defined.

>  You can
> include a namespace in doctest invocations, but I'm guessing the problem is
> that you aren't able to give these settings when using some kind of test
> collector/runner?  More flexible ways of defining doctest options (e.g.,
> ELLIPSIS) would be helpful.

Yeah, doctests has these (globs and M.__test__), it's just that it
takes you out of the mode of "executable documentation" and becomes
less fun.

>> Without #2, "readable docs" nicely co-aligning with "testable docs"
>> tends towards divergence.
>
> IMHO this could be more easily solved by replacing the standard repr with
> one that is more predictable.

Yes, but then this gets more into "my" idea of making a test()
builtin, like help().  In that case, you could do fancy stuff where
you wouldn't even have to test string output.

Cheers,

mark

PS. Darn, I hate when I forget to reply-all...
More information about the Python-ideas mailing list