[TIP] Test discovery for unittest
marius at gedmin.as
Sat Apr 11 05:29:23 PDT 2009
On Fri, Apr 10, 2009 at 10:19:48PM +0100, Michael Foord wrote:
> Marius Gedminas wrote:
> > On Tue, Apr 07, 2009 at 06:04:42PM +0100, Michael Foord wrote:
> >> Marius Gedminas wrote:
> >>> I don't think I can give this discussion the full attention it deserves,
> >>> but I'll at least outline the conventions that the Zope 3 world uses for
> >>> tests:
> > <snip>
> >>> Is this compatible with what you're discussing? I'm kind of wondering
> >>> about the talk about controlling recursion.
> >> It sounds *similar*, except:
> >> - Test modules can be discovered from the file system by a loader /
> >> custom suite
> >> - Tests are loaded in the normal unittest way - by finding all TestCase
> >> subclasses in each module found
> > Zope 3 has some abstract base classes that subclass unittest.TestCase.
> > I believe that's the reason for listing the ones you want explicitly
> > instead of using unittest's autodiscovery.
> The point of discovery is to avoid having to list things explicitly, you
> don't have to use it.
I'm not complaining, I'm explaining. :-)
> If you look at the prototype you'll see that it skips classes that don't
> have any tests on them. If your base classes don't have any tests it
> wouldn't be a problem, if they do (why?) then you can use load_tests to
> skip them.
The "why?" cries for an explanation. Some of the older Zope 3 code has
test cases that can test any particular implementation of an interface.
You have to subclass that test and override the factory method to supply
the implementation you want to test.
The planning fallacy is that people think they can plan, ha ha.
-- Eliezer Yudkowsky,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20090411/d435ee9b/attachment-0001.pgp
More information about the testing-in-python