[Numpy-discussion] ticket 788: possible blocker

Charles R Harris charlesr.harris@gmail....
Tue May 13 17:59:19 CDT 2008


On Tue, May 13, 2008 at 4:40 PM, Stéfan van der Walt <stefan@sun.ac.za>
wrote:

> 2008/5/13 Travis E. Oliphant <oliphant@enthought.com>:
> > Robert Kern wrote:
> >  > On Tue, May 13, 2008 at 11:12 AM, Travis E. Oliphant
> >  > <oliphant@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.
> >  >
> >  That is not true.  You *don't* need to do testing to be sure you
> >  actually fixed the problem in some cases....  Looking at the code is
> >  enough.   Like the case we are talking about.
>
> That is where we disagree: looking at the code is simply not enough.
> It is fine if you know where to look, and if you look exactly there
> every day -- but who does that?  That is precisely why we have tests
> -- to automate this inspection.
>

Stefan, sometimes the fix really is clear and a test is like closing the
barn door after the horse has bolted. Sometimes it isn't even clear *how* to
test. I committed one fix and omitted a test because I couldn't think of
anything really reasonable. I think concentrating on unit tests is more
productive in the long run because we will find *new* bugs, and if done
right they will also cover spots where old bugs were found.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080513/5eff2055/attachment.html 


More information about the Numpy-discussion mailing list