[TheBoff]

It seems to me that most of these aren't controversial at all.

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.

[Chris_Newton]

Surely the edge cases are something you should have carefully considered before starting to code?

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.

[TillE]

Indeed. Writing a unit test makes you think about what kinds of input your code might get. It's one of the few situations where you are specifically prompted to think of possible edge cases.

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:

http://xunitpatterns.com/

[devgutt]

If you are on a pivot vortex, unit testing is evil. Otherwise, it's very helpful to maintainability.

[freditup]

Public fields are still debatable too, at least in some languages. I've worked with / talked to some people who insist that you can never in any case have a public field. I personally believe there are a lot of factors to look at before making that call.