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

[Marius Gedminas]

On Tue, Apr 07, 2009 at 02:47:22PM -0400, Doug Philips wrote:
> On or about Tuesday, April 07, 2009, at 11:20AM, Marius Gedminas indited:
> >On Tue, Apr 07, 2009 at 09:27:59AM -0400, Douglas Philips wrote:
> >> What I want is for everything to come to a screeching halt if there is  
> >> an error -loading- a test module. i.e. before any tests are even run.
> >
> >I'm with Laura on this (see my other email for the rationale), and don't
> >want that to happen.
> 
> We consider an unloadable module to be a fundamental error that calls
> into question the very environment in which the tests are running and
> hence the veracity of any results we might get.

Interesting.  Well, your use case is an interesting one (testing
hardware rather than just software), and maybe you're right to be
careful.

Do you also abort test runs when a test setUp method fails?

> We don't want to start
> chasing down the rabbit hole of trying to reflectively "understand"
> what kind of failure it was and then try to take remedial action (such
> as running other tests).

I guess I just don't see continuation as a remedial action.  If the
tests are properly isolated, then a missing 'import re' in test_foo.py
will not have any influence on the tests defined in test_bar.py.

Let's agree to disagree here.

> YMMV, and seemily does. This is a pretty
> clear layer of separation which should be able to support policy
> (continue if import errors, abort if import errors, etc.) pretty
> generically...

*nod*

Marius Gedminas
-- 
Remember the... the... uhh.....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.idyll.org/pipermail/testing-in-python/attachments/20090408/961a4023/attachment.pgp