[Numpy-discussion] ticket 788: possible blocker
Charles R Harris
Tue May 13 17:59:19 CDT 2008
On Tue, May 13, 2008 at 4:40 PM, Stéfan van der Walt <email@example.com>
> 2008/5/13 Travis E. Oliphant <firstname.lastname@example.org>:
> > Robert Kern wrote:
> > > On Tue, May 13, 2008 at 11:12 AM, Travis E. Oliphant
> > > <email@example.com> wrote:
> > >
> > >
> > >> Besides, having a "test-per-checkin" is not the proper mapping in
> > >> mind. I'd rather see whole check-ins devoted to testing large
> > >> 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
> > > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion