I don't know about you, but I find some aspects of test-driven development hard. Too often I'll find myself writing trivial unit tests, typically revolving around persistence or login. I mean, really, should you be spending time writing tests to ensure your application's persistence layer is functioning correctly? That should just be a given!
However, I've been pushing through my initial hurdles, and am really starting to see some solid payback. One of the unexpected benefits is that my API almost immediately becomes more readable. Not convinced? Think about it. In test-driven development, because you're writing the tests in "problem brain-space" instead of "solution brain-space", you're thinking in terms of the problem that needs to be solved, not how you're going to solve it.
While you're in "problem brain-space", you're in the same sort of place that users or maintainers of your code will eventually find themselves in. There are many possible "solution brain-spaces", each with their own set of unique concepts and terms, but typically in the "problem brain-space" you're more likely to be speaking a common language. Which is a good thing.
