The Arianne project had rather bad experience with people writing their tests first and concentrating on implementing something that fits their tests. This may lead to a lost focus on the bigger picture. And it gets a real issue if those people refuse to look at user visible bugs in their code because the tests are green.
From our experience it is way better to write the tests in parallel to writing the program. This way you concentrate on writing code that fits the general requirements and not just the return value of a method. But writing the tests in parallel to the code (instead of later) will result in code that is well structured for easy unit testing.
Automatic low level tests are very important for two reasons: They speed up development because small parts can be tested without starting up the complete application. And they can catch unintended changes done at a later time.
But they are no substitution for high level tests done by other people than the person who wrote the code. If the person who wrote the code made wrong assumptions it is likely that those wrong assumptions are in his own tests, too.
Keeping the team motivated works best when the member belief in automated testing and there is some progress visible: Public coverage and number of tests chart can be helpful. And of course it is a good idea to praise people for writing high quality tests (e. g. no bogus tests for the sake of stats).
