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.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
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. 🙂