[TIP] Fail-fast testing?

[Michael Foord]

On 06/03/2010 13:16, J. Clifford Dyer wrote:
> 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.
>    

Well, the command line functionality is new, so I can probably default 
to on for the command line interface with API hooks to turn it on for 
the framework authors.

The problem is that this goes into the Python standard library - so if 
people upgrade their Python version and their test framework stops 
working that is bad. Backwards compatibility is important.

All the best,

Michael

> 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
>>
>>      
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.