[TIP] testing: why bother?

C. Titus Brown ctb at msu.edu
Wed Mar 23 09:06:59 PDT 2011

On Wed, Mar 23, 2011 at 03:59:01PM +0000, Jonathan Lange wrote:
> On Wed, Mar 23, 2011 at 3:37 PM, C. Titus Brown <ctb at msu.edu> wrote:
> > On Wed, Mar 23, 2011 at 02:22:06PM +0000, Jonathan Lange wrote:
> >> On Wed, Mar 23, 2011 at 2:09 PM, C. Titus Brown <ctb at msu.edu> wrote:
> >> ...
> >> > (Since I like to argue with Michael...)
> >> >
> >> > IMO, TDD is too big a leap for people without a fair amount of
> >> > programming experience. ?However, once you have a bit of testing
> >> > under your belt, TDD becomes much easier to justify.
> >> >
> >>
> >> What makes you say that, other than an entirely understandable desire
> >> to argue with Michael?
> >
> > I'll just whip out the "I teach undergrads for (part of) a living" card here...
> By all means. If I were playing to win, I would have bluffed and
> pretended to have a similar card. :)


> > It may be that we get our students off to a bad start somehow, but my
> > experience with our 2nd and 3rd year students is that they are so
> > immature as programmers that they often don't get what to test for,
> > they have no idea what a "specification" is, and, as a result, their
> > tests are not clear expressions of anything.
> Your reference to other methods of specification makes me think that I
> should be considering the properties of TDD that I believe would help:
> clear goals; an obvious next step; avoidance of regressions and
> feelings of incremental success. Perhaps there are things that provide
> these properties but avoid the difficulties for immature programmers.

I'd love to find them!

> > Or, to put it another way, learning how to test is just as hard as learning
> > how to program. Since we don't know how to teach the latter, it's not
> > clear to me why we would know how to teach the former :)
> I agree that learning how to test is just as hard as learning how to
> program. I'd also contend that learning how to program well is at
> least as hard as knowing how to test. Being clear on what exactly you
> are trying to do is harder than it sounds and is a vital element of
> both.

Absolutely agreed, and I think this is one of the main benefits of introducing
the testing way-of-thought.  It just hasn't worked out that well for me,
personally, in my classes.

> Also, if we don't know how to teach either, then our know-how ought
> not factor into our decision.

Two problems: social issues (how do you convince people to *change* if
there's no evidence that it's better on the other side?), and local
optimum issues (we have a lot more experience in teaching one way than
the other, so maybe we're at least slightly better at it).

What we really need here at MSU is clear evidence that we can improve, a clear
direction in which to head, and someone with the energy and drive to actually
implement it against institutional inertia.  I'm lacking in all three at the
moment, but could probably muster the energy/drive given direction.  (F*ck
evidence, we don't have any either way ;)

C. Titus Brown, ctb at msu.edu

More information about the testing-in-python mailing list