[TIP] Fail-fast testing?
J. Clifford Dyer
jcd at sdf.lonestar.org
Sat Mar 6 05:16:23 PST 2010
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.
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.
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
More information about the testing-in-python