Coverage doesn't mean anything...

... is like saying "Wii-Fit doesn't make you fit, because you can just step on and off and the game thinks you are exercising".

If you do this, you are just fooling yourself.

Coverage means nothing unless you assume you are working in an environment where developers are writing good unit test. With this assumption, suddenly it becomes a great measure of how much of the code is untested! [or in BDD lingo.. how much of your code is not required to satisfy the current set of automated requirements indicating either a requirements gap or too much code!]

100% Coverage

To my mind 100% coverage should mean all the code we as a team have chosen to test is tested.

If you decide 'generated code doesn't need tests.. as long as the generator is tested and an example is tested' .. then I say you are still 100%

If you decide 'getters and setters don't need testing' that's fine... exclude them from your coverage.

If you explicitly exclude something from your coverage statistics, then tell your tool. In NCover.. you can put attributes on the things you want to exclude.

Do that and you can get to 100%.

I'll leave the decision as to what things should be tested to the reader... for now.

Story points for Estimation

Mike Cohn, author of Agile Estimating and Planning wrote in his comments to his "To Re-estimate or not; that is the question" article ...

"... When I do iteration (sprint) planning I don’t even consider the story point estimates. We grab one item from the product backlog, break it into tasks and hours, discuss whether we can commit and then repeat until full. The story points–as I use them–are for long-term planning. When we plan an iteration and take a lot more time to do so we do it by discussing tasks, hours and commitment."

check out "Why I Don’t Use Story Points for Sprint Planning" for more of his thoughts on this.

What makes a group into a team?

The key difference is that in a team everyone is values equally, so no decision can be made that is not unanimous.

The question then is how do you get unanimous decisions?
My ex-Coworker, Rob Smyth, taught me "the decider protocol". This is very formal and does the job well, but it's the values behind it that are key.

• Never allow 'no resistors' decision making.


• Never allow group decision if any one person is not aligned.


• Give the power to any individual to block any decision but ask them first 'what will it take to bring you in'?

It's all about valuing every individual in the team.

Thank Rob.

How to get TDD to stick

I found this an excellent summary of points on how to help TDD adoption.

Quick Summary :

• Training


• Patience


• Measure Coverage


• Instill Pride in clean code


• Management's Understanding & Support


• Pair Programming


• Sharing Community


• Coding Dojo


• Reading Workshops


• Periodic visits from a Coach