The document discusses test-driven development (TDD), an agile software development technique where unit tests are written before code to verify functionality. TDD follows a cycle of writing a test, seeing it fail, then writing code to pass the test and refactoring code. Benefits of TDD include cleaner code design, easier refactoring and maintenance, and self-documenting tests. However, TDD requires imperfect knowledge at the start and is not a replacement for all testing.

1. 13 May, 2008Test driven development – “If it's worth building, it's worth testing”

2. Why should we use TDD?Because we can't we get the design right from the beginning.Why can't we get the design right from the beginning?Because at the start of the project we have imperfect knowledge about the software we're developing.13 May, 2008Test driven development – “If it's worth building, it's worth testing” 2

3. What is TDD?Software development technique Related to the test-first programming concepts of Extreme ProgrammingTDD = TFD + Refactoring13 May, 20083Test driven development – “If it's worth building, it's worth testing”

4. GoalsTo have a better code coverage test suiteTo have specification before validationTo write clean code that worksBut the real benefits are many more than the goals! 13 May, 20084Test driven development – “If it's worth building, it's worth testing”

5. Principles and general guidelinesWrite new business code only when an automated test has failedWhen a test fails you have made progress because you now know that you need to resolve the problemTDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing.If it's worth building, it's worth testing.If it's not worth testing, why are you wasting your time working on it?13 May, 20085Test driven development – “If it's worth building, it's worth testing”

6. Development cycle I - StepsCreate a test: basically just enough code to fail (testing the test)Run the test to ensure that the test does in fact fail (testing the test)Run minimal code necessary to pass the testRefactor the code Clean upRemove duplicationWrite a new test case …. 13 May, 20086Test driven development – “If it's worth building, it's worth testing”

7. Development cycle II 13 May, 20087Test driven development – “If it's worth building, it's worth testing”

8. BenefitsAn interesting side effect of TDD: you achieve 100% coverage testYou have a short checklist – resolve one piece of functionality at a timeCleaner design than achieved by other methodsThe design is easier to understandThe code becomes easier to work with as the project matures The resulting code is designed for testability 13 May, 20088Test driven development – “If it's worth building, it's worth testing”

9. Benefits – Safety netEvery single piece of functionality added will have a test coverage. If anything ever changes, the developer will know right awayBetter assurance when integrating your code into source controlRefactoring becomes a lot easier, so the codebase can be kept always healthy13 May, 20089Test driven development – “If it's worth building, it's worth testing”

10. Benefits – Usable designCode that you develop through TDD is going to end up looking very different from code you would have written otherwiseYou don't start with a UML diagram, or a detailed class header file, or anything like thatYou start by using the feature you're about to implementYou're going to be your first user of your code, and you're going to think about how to use it from the beginning13 May, 200810Test driven development – “If it's worth building, it's worth testing”

11. Benefits - ModularityThis is another side effect of having to use the code you're about to writeIsolated, modular tests => modular codebaseA highly modular codebase will compile much more quickly than one that has grown organically13 May, 200811Test driven development – “If it's worth building, it's worth testing”

12. Benefits – Documentation builds itselfThe tests you write while doing TDD are the ideal low-level documentation for your code For every feature, you have at least one example on how to use it correctly and how it's expected to be used. And the best part is that it can't ever get out of date.13 May, 200812Test driven development – “If it's worth building, it's worth testing”

13. MisconceptionThe unit tests form 100% of your design specificationYou only need to do unit testTDD is sufficient for testingTDD doesn'tscaleYour test suite takes too long to runNot all developers know how to test. Everyone might not be taking a TDD approach.13 May, 200813Test driven development – “If it's worth building, it's worth testing”

14. Tools Visual Studion Team System Test toolsNUnitNCoverTestDriven.NET13 May, 200814Test driven development – “If it's worth building, it's worth testing”

15. Example using NUnit/VS integrated toolLink to VS Solution13 May, 200815Test driven development – “If it's worth building, it's worth testing”

16. Referenceshttp://www.developer.com/design/article.php/3622546http://homepage.mac.com/hey.you/lessons.htmlhttp://www.gamesfromwithin.com/articles/0502/000073.htmlhttp://msdn2.microsoft.com/en-us/magazine/cc163982.aspxhttp://www.artima.com/intv/testdriven2.htmlhttp://www.parlezuml.com/tutorials/agiledotnet/tdd_nunit.pdfhttp://en.wikipedia.org/wiki/Test-driven_development13 May, 200816Test driven development – “If it's worth building, it's worth testing”

17. 17Test driven development – “If it's worth building, it's worth testing” 13 May, 2008