[Numpy-discussion] ticket 788: possible blocker

Travis E. Oliphant oliphant at enthought.com
Tue May 13 16:09:20 EDT 2008


Charles R Harris wrote:
>
>
> On Tue, May 13, 2008 at 11:25 AM, Robert Kern <robert.kern at gmail.com 
> <mailto:robert.kern at gmail.com>> wrote:
>
>     On Tue, May 13, 2008 at 11:12 AM, Travis E. Oliphant
>     <oliphant at enthought.com <mailto:oliphant at enthought.com>> wrote:
>
>     >  Besides,  having a "test-per-checkin" is not the proper mapping
>     in my
>     >  mind.   I'd rather see whole check-ins devoted to testing large
>     pieces
>     >  of code rather than spend all unit-test foo on a rigid policy of
>     >  "regression" testing each check-in.
>
>     Stéfan is proposing "test-per-bugfix", not "test-per-checkin". That is
>     eminently feasible. You need to do some kind of testing to be sure
>     that you actually fixed the problem. It is simply *not* *that* *hard*
>     to write that in unit test form.
>
>
> I'll add that every time I've tried to write comprehensive tests for 
> subsystems while cleaning up code, undiscovered bugs show up: complex 
> arccos using the wrong branch, some logical operators having the wrong 
> signature. I expect the first has been there since numeric prehistory, 
> and the second for several years. Those aren't subtle bugs, they are 
> just bugs.
>
> Now that development has slowed down, I think it is time to start 
> working on comprehensive tests that verify that numpy works as 
> supposed. This will also help us pin down what the specs for various 
> functions actually are, something that can be a bit nebulous at times.
I'm completely supportive of this kind of effort.  Let's go write unit 
tests and stop harassing people who are fixing bugs.

-Travis






More information about the NumPy-Discussion mailing list