Where did you learn to unit test? How did you learn?

[Steven Taschuk]

Quoth Skip Montanaro:
> 
>     * What exactly is a unit test?
> 
> A set of unit tests is an executable specification of the functional
> requirements for a piece of software.  A single unit test associates a
> particular input with an expected output.  For each test you are saying, "If
> I execute X, the result should be Y."  If that's not the case, the test
> fails.  (Of course, if it succeeds there is still the possibility that you
> wrote the test incorrectly. ;-)

Elaborating on this last point:

"What tests the tests?" is a reasonable question.  Doctrine on
this point is that the tests should be so simple that they can be
seen to be correct just by reading them.  Thus, they are "too
simple to break".

This doctrine also applies to the code under test; don't bother
testing something if it's too simple to break.  A canonical
example is accessor methods (in languages which make heavier use
of them, such as Java):
    private int x;
    public int getX() {
        return x;
    }
Don't test this kind of thing; it could only fail if the JVM or
compiler goes haywire, if the hardware fails, or something of that
order.  In other words, a test of such an accessor is not actually
a test of the accessor; it is a test of the JVM, the compiler, the
hardware, etc..  That's a waste of your time.

(Of course, if getX() at some point became more complicated,
computing its return value or something, *then* it might deserve
some tests.)

Dave Brueck stated the underlying principle very nicely here about
a week ago: "test until the cost of a bug in deployed code is
lower than the cost of finding the bug through more testing".

-- 
Steven Taschuk                                7\ 7'Z {&~         .
staschuk at telusplanet.net                        Y r          --/hG-
                                            (__/ )_             1^1`