Nathaniel Talbott wrote:
> 
> There's more info on all of this at http://lapidary.sourceforge.net/docs/
> [...] If you have any further questions/comments [..], please, let me know.

in the docs introduction you write:

> [..] One of the keys to good unit testing, though, is not just writing
> tests, but having tests.  What's the difference?  Well, if you just write
> a test and throw it away, you have no guarantee that something won't
> change later which breaks your code. If, on the other hand, you have tests
> (obviously you have to write them first), and run them as often as possible,
> you slowly build up a wall of things that cannot break without you
> immediately knowing about it. This is when unit testing hits its peak
> usefulness.

Recently, in a thread entitled "IT World Interview with Robert C. Martin"
crossposted to news:comp.object and news:comp.software.extreme-programming
Martin offers a subtly, but IMHO *substantially*, different version of
the "peak usefulness" of unit tests: test-first programming.  Martin wrote:

> I have come to realize that there is a practice that vastly
> improves my ability to write software; and I have seen it vastly
> improve the ability of others as well.  That practice is called
> test-first programming. 
>
> When you program test-first, you write unit tests before you write
> production code.  You do this in tiny increments, writing a little bit
> of a test case, and then making that little bit pass by writing a
> little bit of production code.  You never write any production code
> unless it is to make a failing test case pass.  (See "A Programming
> Episode" and "Working Backwards" in the 'publications' section of
> http://www.objectmentor.com for more information on this.)

with emphasis on "you never write any production code unless it is to
make a failing test case pass."

-- 
bil <http://abweb.larc.nasa.gov/~kleb/>