[TIP] Fail-fast testing?

[J. Clifford Dyer]

I would tend to agree with doug, insofar as a broken test gets noticed
right away, but doesn't actually cause the program to fail.  A warning
in the changelog and the documentation should be sufficient.  

Still, the decision is yours, and I'm not going to squawk loudly at
defaulting to off.

Cheers,
Cliff


On Sat, 2010-03-06 at 07:47 -0500, Doug Hellmann wrote:
> On Mar 5, 2010, at 5:50 PM, Michael Foord wrote:
> 
> > On 05/03/2010 22:30, Doug Hellmann wrote:
> >>
> >> On Mar 5, 2010, at 5:12 PM, Michael Foord wrote:
> >>
> >>>
> >>> It would be really nice to have the ctrl-c handling default to on,  
> >>> but perhaps an easy way of handling this is just have it default  
> >>> to off.
> >>
> >> It seems like tests that want to trap Ctrl-C are probably in the  
> >> minority of the set of tests that would use the test framework, so  
> >> defaulting to "on" with a way to control the setting should be safe  
> >> enough.
> >>
> > Yeah, the only danger is the few tests that do strange things (that  
> > used to work) will then be broken under new versions of unittest.
> >
> > Apparently the bazaar tests *don't* install a signal handler, but do  
> > test that they respond to ctrl-c by sending SIGINT. Putting a  
> > handler in by default would then break those tests. Sounds like it  
> > has to be off by default.
> 
> Meh.  Upgrading libraries requires changes, especially when new  
> features are involved.  It's up to you, but I'm unconvinced.
> 
> Doug
> 
> 
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>