[TIP] suitability of unittest.py for large-scale tests

Olemis Lang olemis at gmail.com
Mon Apr 6 07:11:51 PDT 2009

On Sat, Apr 4, 2009 at 10:54 AM, holger krekel <holger at merlinux.eu> wrote:
> On Sat, Apr 04, 2009 at 14:23 +0100, Michael Foord wrote:
>> holger krekel wrote:
>>> [snip...]
>>> I think others did good postings and i agree (and also mailed
>>> so) that the current addCleanup suggestions make some sense to me.
>>> However, in Python voting style i'd say "-0" on it.
>>> Why? I tried to give background for my views that
>>> 1) unittest.py is maybe not the right place to drive larger scale
>>> tests.
>> Do you mean that you don't think unittest is suitable for testing of
>> large applications or large systems?
>> If so then could you elaborate? Of all the Python  test frameworks it is
>> probably the most proven in this area of course.
> do you mean unittest.py is the most proven in the area
> of large scale tests?
> I regard many test frameworks and methods fit for
> purposes that unittest.py does not really cover.
> texttest, selenium or doctests are often better suited for
> acceptance or certain functional testing.  and buildbot or
> py.test better for integration testing.  And the likes of
> Windmill, twill or figleaf help with certain kinds of testing
> that do not depend on JUnit style setups.

Message is too long ... however the only thing I wanted to add here is
that I consider XUnit valuable for the backend ... IMHO a possible
roadmap is as follows :

- Step 1: Use all those mentioned above (e.g. texttest, selenium,
doctests, buildbot, py.test, Windmill, twill, figleaf ... ), to
specify what needs to be tested ... I really prefer these and not
unittest style since it's a general purpose approach ... while the
former are more specific and thus more useful ...

- Step 2: Write unittest loaders to load each kind of test ... (e.g.

- Step 3: Write generic loaders (e.g. dutest.PackageTestLoader,
dutest.MultiTestLoader) to build the test suite the way you want and
combine the more specific loaders to solve a particular problem.

- Step 4: Write the specific runner you need (e.g. PydevTestRunner ...
and this is just e.g. ;)

- Step 5: Integrate all this with distutils maybe hiding the
complexity involved by using config files or a similar mechanism ...

All this is with respect to a possible unittest evolution ... other
framws might have something like this already ... ;)

PS: Random thoughts ...



Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

More information about the testing-in-python mailing list