Notes:
A unit test exercises "a unit" of production code in isolation from the full system and checks that the results are as expected. The size of "a unit" to be tested depends on the size of a set of coherent functionality and in practice varies between a class and a package. The purpose is to identify bugs in the code being tested prior to integrating the code into the rest of the system. The reason for identifying bugs before integration are it is far easier (quicker and cheaper) to:
Identify and correct problems (and demonstrate that the solution works) in isolation.
Correct problems that one is familiar with because one wrote it recently.
The approach we followed is for the developer to develop the interface, the test harness, and the implementation. (In roughly that order - although some parts of the implementation may be completed before unrelated parts of the test harness).
JUnit provides a framework to facilitate the running of tests, recording of results and reporting of errors.
In the pilot project the use of unit tests has had a very visible effect on both the scheduling (tasks rarely overrun because of the need to debug "finished" code already in the project codebase) and morale (development tasks have clearly delimited boundaries - and didn't drag on with bugs surfacing weeks or months afterwards).
I've described how we used JUnit elsewhere – C Vu 13.5. This also available from my website:
http://www.octopull.co.uk/java/Introducing_JUnit.html
Contrary to the suspicions of management developers like to get their code to work. As one of them said to me "this is great – I like getting things right first time!"