TITLE: Do Things That Help You Become Less Wrong
AUTHOR: Eugene Wallingford
DATE: February 14, 2014  3:07 PM
DESC: 
-----
BODY:
My students and I debriefed a programming assignment in class
yesterday.  In the middle of class, I said, "Now for a big
question: <B>How do you know your code is correct?</B>

There were a lot of knowing smiles and a lot of nervous
laughter.  Most of them don't.

Sure, they ran a few test cases, but after making additions
and changes to the code, some were just happy that it still
ran.  The output looked reasonable, so it must be done.  I
suggested that they might want to think more about testing.

This morning I read a great quote from
<A HREF="http://nathanmarz.com/blog/interview-with-programmer-magazine.html">
   Nathan Marz</A>
that I will share with my students:

<BLOCKQUOTE><EM>
 Feedback is everything.  Most of the time you're wrong, and
 feedback is the only way to realize your mistakes and help
 you become less wrong.  This applies to everything.
</EM></BLOCKQUOTE>

Most of the time you're wrong.  Do things that help you become
less wrong.  Getting feedback, early and often, is one of the
best ways to do this.

A comment by a student earlier in the period foreshadowed our
discussion of testing, which made me feel even better.  In
response to the retrospective question, "What design or
programming choices went well for you?", he answered <EM>unit
tests</EM>.

That set me up quite nicely to segue from manual testing into
automated testing.  If you aren't testing your code early and
often, then manual testing is a huge improvement.  But you can
do even better by pushing those test cases into a form that
can be executed quickly and easily, with the code doing the
tedious work of verifying the output.

My students are writing code in many different languages, so I
showed them testing frameworks in Ruby, Java, and Python.  The
code looks simple, even with the boilerplate imposed by the
frameworks.

The big challenges in getting students to write unit tests are
the same as for getting professionals to write them: lack of
time, and misplaced confidence.  I hope that a few of my
students will see that the real time sink is debugging bad code
and that a fear of changing code is a lack of confidence.  The
best way to be confident is to have evidence.

The student who extolled unit tests works in Racket and so has
test cases in
<A HREF="http://docs.racket-lang.org/rackunit/">
   RackUnit</A>.
He set me up nicely for a future discussion, too, when he
admitted out loud that he wrote his tests first.  This time,
it was I who smiled knowingly.
-----