I disagree with one of the points supporting "Unit testing won’t help you write good code.", though, where he implies that writing the code reveals the edge cases. Surely the edge cases are something you should have carefully considered before starting to code? I've found that crystallising the edge cases as a test before writing the function can be really helpful.
There are two kinds of edge cases: the essential ones that derive from your requirements and problem domain, and the accidental ones that result from implementation details like your choice of programming languages or which libraries you use or your software architecture.
You can try to identify the essential ones and write tests for them in advance, but for the accidental ones there’s only so much you can do with a black box approach to testing.
TDD doesn't work well in every problem domain. Sometimes you have to accept that parts of your code can't reasonably be unit tested, and isolate the bits that are testable. But where it is a good fit, it's magic. My favorite book on the subject: