[TIP] unittest2 discovery / doctest integration?
olemis at gmail.com
Thu Apr 29 11:46:52 PDT 2010
On Thu, Apr 29, 2010 at 9:24 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 28/04/2010 22:53, Pete wrote:
>> On Apr 28, 2010, at 4:26 PM, Pete wrote:
>>> Appears the way to do this goes like so. In your mostly-unittests test
>>> module, define a load_tests:
>>> def load_tests(loader, tests, ignore):
>>> return tests
>>> Pretty straightforward, though not at all obvious. Looks like the
>>> documentation for doctest could use an update...
>>> http://docs.python.org/dev/library/doctest.html#unittest-api I'd write a
>>> patch (hello-to-my-friend-jesse-noller), but I'm not entirely sure what to
>>> say (tl;dr) - would replacing the code sample& changing its description to
>>> read "To integrate with unittest discovery, include the following in a
>>> module of unittests:" suffice?
>> I just went ahead and created bug 8564 w/ a patch if anyone cares. Thanks
> Using load_tests seems like the best way to integrate doctests with unittest
> test discovery to me.
I suppose I *can* and *will* disagree ... JFTR and without flamewars
> When unittest is more extensible
I really don't see the need for more extensibility than we have today
in order to get this done, specially since it's already done by e.g.
`dutest` . Using dutest classes (especially `PackageTestLoader` and
`MultiTestLoader`) anybody should be able to load any kind of test
cases, including wrappers -adapters- for particular test styles |
frameworks, from anywhere within a (file-system) package structure or
a subset of this structure, and make that decision anywhere (not just
> there may be a better
> way (creating a doctest loader to inspect modules), but for now this is the
> best way.
Like those in `dutest` ? How much different will they be ? Just curious ...
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
TracAMF: Committed first (working) version based on thijs patch. -
More information about the testing-in-python