One question that arises is how much test code should you expect to write if you are aiming to ‘test everything that could possibly break’. Our experience is looking like 1 to 1.5 times the amount of production code that you have. A lot of people balk when they see this figure, but our experience is that if you hit it, the number of bugs found in any exploratory phase drops dramatically and is focused in areas where existing TDD tooling is weakest (complex event driven UIs and multi-threaded code seem to be two areas of concern). Simply put we find it difficult to exercise tests in those areas, so we expect a bug count during exploratory testing.
Personally I would focus less on using this ratio as a metric than ensuring that you keep your code coverage high and that your tests adequately prove the operations on your domain objects. Just do not be suprised if you end up writing as much test code as production code or more.
I would be interested in hearing from other TDD projects on the ratio of test code to production code they have, and how that reflects on the code coverage they have. Feel free to leave a comment.