[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