Unit testing is a topic near and dear to my heart. It was at about this time last year that I was really getting myself up to speed with Google Testing Blog and also Adam Goucher's QA blog.
All of this reading and testing has pointed out some weaknesses in unit testing experience.
1. A developer sitting down to write code is less likely to unit test if they don't already have some idea of unit tests they are to write. If you're not working in an Agile shop, (let's face it, there are lots of us that don't) this can be intimidating. What if you don't write enough tests or test the right way? How should this thing you're supposed to write be unit tested anyway?
2. Code coverage tools, such as this post. So what are they really telling us about tests anyway?
3. How many tests should developers be writing? This question, above all, seems the least answerable. Google had a post that addressed this very question, and even their answer was a very murky, "it depends." They qualify their "it depends," by saying, "it depends on how much confidence the tests can provide in the face of changes made by others." Um...sure. Thanks for the really practical answer (not, really).
Now that unit testing frameworks are more fleshed out, I'd like to see more tools surrounding the tests that address these issues. Have interesting tools or war stories? Please leave a comment.