Should Test-Driven Development be in the beginners tutorial?

Ralph Johnson johnson at cs.uiuc.edu
Fri Sep 22 11:17:31 UTC 2006


On 9/21/06, Matthew Fulmer <tapplek at gmail.com> wrote:
>
> I really want to introduce beginners to (and learn myself) how
> to write good unit tests, then develop a  class that conforms to
> those unit tests inside the debugger. I have heard that that
> capability is one of the best things about Smalltalk, and I know
> that unit tests are a *very* good thing to use.
>
> Should I expose a Squeak beginner to this topic early on?
> or should that be the topic of a separate tutorial?

>From the beginning.

One of the key ideas in programming is the difference betwen an abstraction
and its implementation, between the "outside" and the "inside" of an object.
An object has an interface and it has an implementation, even in Smalltalk.
Ideally, if you want to use an object, you can just learn its
interface and you don't
have to learn its implementation, though the ideal is rarely met.  But
to think about
a large system, you have to focus your mind on a small part and ignore
the details
of the rest.  And then you switch to another small part, and another,
and another.
Sometimes the "small part" is the architecture, so it encompasses the
entire system,
but you still have to focus on one part of the system and ignore the
rest, because
of the limitations of the human brain.

Unit tests are a very good way to think about the outside of an
object.  They aren't
the only way.  Little scripts in a workspace, example applications
that use the object,
and "all senders" are other ways.  But unit tests are a very good way
and should be
emphasized from the beginning.

However, do not say "first write tests, then write a class".  This is
as wrong as "first
write class, then write tests".  The inside and the outside view of an
obect are both
essential.  You can't get a good class unless you think of them both.
So, you will
first start with a simple inside and outside view, then you'll
gradually make it more
sophisticated.    This means you will write your tests and the methods
together.
Perhaps you'll first write a test, then a method, or perhaps you'll
write a few methods
and then a few tests.  What is important is that you think of them together.

Not all classes have unit tests.  If you develop a class by
refactoring your code,
such as by generalizing a couple of concrete classes to factor out a
common superclass,
or by converting a case statement into polymorphism and splitting out
some strategies,
then the original code will have tests and they will execute the new
class as a side
effect.  The application that uses the new class shows its outside
view.   A quality
assurance expert would probably want to write some new tests for the new class,
but a designer probably would not.  That is because the designer is
mostly interested
in the tests to help define the outside view of an object, and the
tests aren't needed for
that.  I don't think you should try to teach the QA point of view of
testing in an introductary
programming course, but you should definitely teach the designers
point of view of testing.

-Ralph Johnson



More information about the Squeak-dev mailing list