For a typical project of ours, it normally takes 10 minutes to run all 300+ unittests. No wonder that I overheard the following conversation in the office yesterday
Pančo: Why are you playing Manic Miner? Tom: I'm waiting for unittests to finish. Pančo: Oh. Carry on.
When you develop new code and corresponding unittests, one normally doesn't put lot of attention to execution time of unittests. After all, a typical unittest takes imperceptible amount of time to execute. But once you multiply this imperceptible amount of time by the factor of 300 or more, the total running time of unittests becomes very apparent.
I think that total execution time of unittests should not excede 10 seconds. That's probably the maximum time that you're willing to just sit and observe unittests being run, without switching to some other context (like playing Manic Miner). Since our bigger projects are covered by more than 300 unittests, a logical consequence of limiting total unittests execution time to 10 seconds is that a single unittest should not take more than 30ms to execute. But since our test coverage should be at least tripled, I would prescribe that a single unittest shouldn't take more then 10 miliseconds to execute.
With our current situation of unittests requiring 600 seconds to finish, we are still very far away from the goal of unittests not slowing us down. But as is the case with almost everything, patience and perseverance deliver results.