[Python-Dev] Proposed unittest changes

Nick Coghlan ncoghlan at gmail.com
Fri Apr 25 08:54:34 CEST 2008

Neal Norwitz wrote:
> All the expect methods duplicate the assert methods.  Asserts can the
> test to fail immediately, expects don't fail immediately allowing the
> test to continue.  All the expect failures are collected and printed
> at the end of the method run.  I was a little skeptical about assert
> vs expect at first, but it has proven useful in the long run.  As I
> said, I don't think this should be done now, maybe later.

I'd agree these kinds of things can be very useful, particularly for 
tests which run the same test for multiple inputs - when those tests die 
on the first set of input values that do the wrong thing, it greatly 
slows down the test-fix-retest cycle, since you have to go through it 
multiple times. If the test is written to test all the input values, 
even if some of them fail, and then report at the end "test failed, here 
are the (input, expected_ouput, actual_output) that didn't work" it can 
make tests far more efficient.

At the moment I do it manually by collected a list of failed triples, 
then reporting a test failure at the end if the list isn't empty, but 
something like "expect" methods would avoid the need to recreate that 
infrastructure every time I need it.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list