[bjourne]

I get what you mean with the tip of the iceberg analogy. The problem is that you can't write any insightful tests before you have written the structure of the application and you can write the application before you have written the tests cause of TDD.

So what I do is that I first hack out the application before I write any tests. E.g if I code a matrix multiplication routine I'm not going to waste time writing unit tests for it. Cause perhaps a few hours later I might realize that I don't need matrix multiplication after all. An added benefit is that I don't have to constantly "context switch" between test writing mode and implementation writing mode.

I write tests when I have something interesting to test. So if the application unexpectedly crashes when I run it I write a test that triggers the crash. Then I fix the bug which causes the test to pass. I find these types of tests to be much more valuable than the "cookie-cutter" unit tests TDD expects you to write.