reliance on debuggers is a wierd strange concept. Debuggers are utterly incapable in multithreaded environments. Just write damn unit tests and simulations!
Depends on the debugger, really. One thing the Visual Studio team's been doing lately that I appreciate is working on improving their multithreaded debugging story. Nice visualizations for keeping track of parallel call stacks and whatnot. The actual step debugger itself still leaves much to be desired - the UI doesn't give you a lot of help with keeping track of when a context switch happens, for example - but even there it's not utterly incapable.
When was the last time that a unit test caught a race condition ? When was the last time a unit test caught a contract violation (one subsystem doesn't agree with another about the semantics of a piece of data) ? When was the last time a unit test caught the use of an O(n^large number) algorithm in a production system ?
Unit tests verify if the programmer's understanding of the code matches reality.
That's all. Not saying it's useless, but a) it's at best a start of proper testing, b) insisting on coverage is beyond useless.
What is needed is a test if the programmer's understanding of the problem is up to par. Since that's impossible, let's go with the programmer's understanding of the whole program : system and loadtests.
Unit tests, while useful for TDD for "fiddly" code, are useless to guarantee correctness of an application. System tests are better. Proper type system abstractions are best.
