Recent Readings of Interest
At the suggestion of a friend, from time to time I’m going to post about Recent Agile (or related) articles that I’ve read and found interesting.
Yet another misunderstanding of TDD, testing, and code coverage – In examining the failings of Kevin Pang’s “Is Code Coverage Really All That Useful?” – Christian Gruber provides an excellent description of the real value of Code Coverage in Unit testing
At the Scrum Gathering in Stockholm, Bas Vodder presented: Problems with component teams – where he explains why Feature Teams are better than Component teams. Related from InfoQ: Choose Feature Teams over Component Teams for Agility.
A Leaner Start: Reducing Team Setup Times – from last year, Patrick Kua wrote about reducing the time and pain involved in introducing new members to the team.
Testability Explorer: Measuring Testability from Misko Hervey – the tool itself is here: Testability Explorer – I’m not sure how I feel about this tool yet since some of Misko’s claims in his talk don’t sit well with me yet. Specifically he suggests no use of statics at all ever – never again calling Math.Abs() directly. Hmmmm.
Keith Braithwaite – has a interesting presentation on some measurement work he did. Measure for Measure. Its a bit hard to read by itself – but the key message for me: projects that have automated Unit tests have less complex code.
Mark Shuttleworth of Ubuntu fame mentions the use of TDD in the development of their distro.
If you enjoyed this post, subscribe now to get free updates.
Did you love this post?
Then please share it!
November 23, 2008 at 5:37 pm | Misko Hevery
To clarify, I said, in my code I don’t create statics. I have no choice but to call Math.abs(). And I am not going to wrap it in another class just to stick to my guns.
Math.abs() is not a problem since it is a leaf of a call graph. Static methods become a problem when they move closer to the main method. With main method being the worst.
Suppose you have User.get() where inside of it you talk to the the database to fetch the user. The issue here is that you can’t prevent User.get() from executing. Sprinkling your code with Math.abs() is benign. But User.get() will make it impossible to test.
The other problem is that suppose you have a benign method such as ID.parse() which converts a string to some typesafe id. What if you change the strategy and put some calls to the DB inside to ID.parse()? You just went from benign to problem. The point is that static method is a slippery slope. And it is very easy for it to be a problem.
So I have a simple policy. No static methods in the code I write.