SWP: IME, you need a good harness for running the tests. Unfortunately, JUnit is almost non-existent - it does practically nothing - and I've been watching it for ages hoping it would (eventually) grow and gain a complete set of harnesses...
If you look around the junit site, you can find lots of 3rd party harnesses and if you're lucky may find ones that suite you. But there aren't that many
For instance, we've coded unit-testing support directly into the core gameserver for the GrexEngine; this means that writing new unit tests is fairly simple: you can assume that the whole gameserver is already up-and-running and that various config and init stuff has already happened. This is more than just an "init-stage" for the unit-tests (can't remember what jargon name junit uses for it
), because the tests themselves are only invoked from inside a pre-configured pre-started game-server. If you invoked the tests from outside the game-server, and had "starting the server" as part of the test, it would add minutes to the exec time of every test, and would be very error prone and hard to maintain.
The other part of unit-testing where you can save a lot of time is by learning to be cunning about the tests you run. XP people often say "test everything in the contract, then add a test for every bug you ever find", which is good, but...there's definitely a mindsight that lets you write new unit tests from scratch about 5 times as efficiently as if you do so naively. I'm pretty sure there are articles spread out on the web which offer advice on getting into this mindsight, although I've not yet seen a "thinking in unit-tests" (come on, Bruce!)
which would be very helpful to many people I suspect.
I find that the most effective *initial* unit tests are ones written by ignoring the spec and all the implementation. Instead, start from the use-cases (if you don't know what use-cases are, do a google; they're a simple concept used widely, e.g. in UML design). Just write unit-tests that mirror the use-cases; this generally is a lot less than testing the contract of the method/API and yet exercises 99% of the downtime/damage that bugs will cause to user-code: people code to contracts less closely than they code to use-cases