Really TDD-ing: Less simple than you think
TDD is a pretty simple system, as popularly described. For an individual doing a kata or playing with some example code it is really just three steps. On card #44 of AgileInAFlash it looks like this: It's the right way to think about TDD, and the right way to get started. When you get to a real project in a team environment you have many other issues to consider. In a modern team environment, with a DVCS, it looks more like this: Get the current code ( git pull , get clone , hg pull -u , whatever) Run all the tests and be sure they're all really green, to avoid blaming yourself for unrelated breakages. If there are no tests, write a trivial failing test (" assertTrue(false) ") to prove your testing setup (ide, scripts, makefiles) really work. Then delete the trivial test. Write one "real" red test. INSIST ON RED. Write code to turn it green. Local commit "save your game" Refactor (or intentionally choose not to). Check to...