

Class Registration
“Test-driven development [TDD] is dual-entry bookkeeping to prevent errors in your code.”
I was lucky enough to see Uncle Bob give a presentation on TDD this week. During his demonstration of the Bowling Game, I noticed he refrained from writing tests for the all the little helper methods he extracted during the course of the test-code-refactor cycle. In the past, I had a tendency to take these private methods, make them public and write tests against them. Something never felt right doing it, but it never hurts to have more tests, right?
However, after watching Uncle Bob, I understand why you don’t need to do that: the original method that spawned all the little helper methods is already well-tested. If there was a defect in the private helper method, the public method will inform you. Intuitively, I knew that and was beginning to go there. Uncle Bob just moved that process along faster, so thanks!
Agile Agile Design Agile SD Book Reviews Burndown Charts Certified Product Owner Certified ScrumMaster Class Design Coaching Collaboration Communication Conferences CSP Fast Pass Daily Scrum Definition of Done Design Excellence Design for Six Sigma Distributed Teams Documentation Español Estimating & Planning Extreme Programming Games Innovation Games Interviews Intro to Scrum Lean Legacy Code Links of the Week Measures Meetings Metrics Migration Movies Open Workspace Pair Programming Personal Planning PMI Powerful Questions Practices Presentations Press Release Product Backlog Product Owner Quality Refactoring Retrospectives Rugby Scrum ScrumMaster ScrumMaster Plus Servant Leadership Simple Design SIMSOC Spain Sprint Backlog Sprint Goal Sprint Planning Sprint Review Stakeholders Task Board Team Test-Driven Development Testing The Core Tools Training Training From the Back of the Room Transitions Travel Uncategorized User Stories Vision Voice of the Customer