There is another way better way. Program to interfaces. Or write out all the methods you need, have empty bodies, and implement them one by one. From the lower level/helpers, to the higher level ones. If any method becomes too large, or if there is a lot of redundancy, break it in smaller units.

I think TDD hampers design, as it places a penalty on every time you want to reactor code while you are still implementing it and it keeps you vested on current code, which is against the "keep it simple, and easy to change" principle. In languages like java, it may force you to break encapsulation and good design, just to have your code tested. (how many times have you see this comment: "don't use this, just for testing purposes") in side of methods.

If you must do testing, a functional level testing is much better. Where you test only the higher level methods that have are acting on the functionality, but don't care about the lower level/helper methods.

Take the holistic approach, and don't sweat the details. If you do a good job on breaking the implementation in small/reasonable sized methods, then it is easy to spot errors when you are developing. Try the best to avoid methods with side effects (modifying shared resources), and keep the methods dumb: input in, input out, no side effects.. Just test the one method that is being called for that particular functionality, and if everything is working well, your overall test should come out as positive.

What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types.