Test Driven DevelopmentRequirements are written beforeimplementation, using tests (unit/integration)Production code is only written to make thetests pass - in other words, only to satisfyrequirements!If theres not a requirement (hence a test)...You Aint Gonna Need It!
TDD CycleRED: write a test for arequirement that has notbeen implemented yet...GREEN: write the minimumcode to make the testpass...REFACTOR: do not repeatyourself, extract methods,remove code smells... tidyup the camp!
TDD Rules● No production code can be written withouta test● The test should ALWAYS fail before startingto write code● Drive objects and methods creation fromthe test, using your IDE● Do the minimum required to have yourcurrent test pass without breaking theprevious● Never skip refactor phase!!!
TDD Best Practices● Write your asserts first● Outside-In approach● Never refactor on a failing test● Write Class Responsibility Collaborationcards in advance● Drive collaborators development by testinginteractions with the current class
TDD Benefits● Testable code● High coverage (but coverage is not agoal...)● Nothing more than what needed isdelivered (no surprises)● Clean code (provided refactoring is neverskipped)● Productivity improves with time -developers have trust in changing the code(new features and maintenance)
TDD Myths (aka Disclaimer)● TDD immediately gives you all the benefits○ The learning curve is steep, but in the mid-termpays off with higher productivity and less defects.○ Should be gradually introduced and practiced● TDD gives you 100% bug-free code○ Drastically reduces the bug rate but...Program testing could show the presence of bugs,never their absence!E. Dijkstra