A better unittest

[Duncan Booth]

[posted and mailed]

Thomas Heller <theller at python.net> wrote in news:he8xgr3g.fsf at python.net:

> This looks great, but has problems. It is slow. For some input, at
> least.
> 
> I didn't have enough patience to wait for the output of your script,
> instead I changed the 10000 character strings to 100 characters and then
> it only took some seconds.

I'm confused.
On my machine, the test.py with 10000 character strings has a total running 
time of about 1/2 second. Are you saying it takes significantly longer on 
your machine?
...
a little later
...
Ok, now I see the problem. When I tried applying your patch to unittest.py 
in Python 2.2.2, it complained, so I applied it to Python 2.3. Some change 
between the two means that the comparison code is blindingly fast on 2.3 
and depressingly slow on 2.2.
 
> 
> Maybe you should create a new method (failUnlessEqual_ShowDiff or so)
> which will do the fancy formatting.
> 
> Maybe the diff formatting should be put into the TestReport, so that
> at least the
>     FFFF
> line is printed more quickly, and the formatting doen afterwards.
> 
> Maybe a time limit should be introduced.
> 
The first one might be good. A better move though is just to replace the 
2.2.2 difflib with the one from 2.3 (and enable generators and add a python 
definition of enumerate). This brings the running time down to something a 
bit more manageable (although I haven't checked that it hasn't broken 
difflib for other purposes).

The difference code could actually be made much faster quite easily. If I 
added a search for the first difference, then I could do the ellipsis and 
truncating first and only pass what is left to difflib.

-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?