1. © ALEXANDRE CUVA  VERSION 2.00 Test Driven Design

4. Alexandre Cuva Agile Transition Coach, Scrum Master, Product Owner Management 3.0 & Certified Scrum Developer Trainer Event speaker Hermes Swiss Project Team Professional ITIL V3 “I coach teams and organization to become highly productive.” http://www.slideshare.net/GToronto Agile Transition Coach

5. Why should developers write tests? - 5 - Common responses:  “leave testing to QA”  “developers are too busy”  “developers don’t know how to test”  “We don’t have bugs”  “developers are intimately familiar with the structure of the code and are not well-suited for testing it”

6. But - 6 - “if developers don’t test. How do they know that they are producing quality software?” Tests are a tool to help developers take responsibility for quality Tests help making small steps and give immediate feedback Test help maintain focus on measurable outcome of coding – producing the code that accomplishes a concrete objective

7. Kent Beck say Good unit tests … - 7 - Express intent, not implementation details Run fast (they have short setups, run times, and break downs) Run in isolation (reordering possible) Run in parallel Use data that makes them easy to read and to understand

8. Testing - 8 -

9. TDD - 9 -

10. TDD - 10 -

11. How to do it - 11 - Design: figure out what you want to do Test: write a test to express the design  It should FAIL Implement: write the code Test: run the test  It should PASS

12. Test Unit Framework - 12 - Microsoft Test MSTestIncluded inside -VS2010 Professional -VS2008 Team System NUnitMost Used Open Source More upToDate than MSTest xUnitFork from NUnit Most Used Open Source ?

13. Visual Studio - 13 - Have always a separate project for your test.  Unit Test : xxxTest  ATDD : xxxAcceptanceTest  BDD : xxxSpec  Integration : xxxIntegrationTest

14. Visual Studio - 14 - On Visual Studio :  Create a Project “Test Project”  Add new Test  Select “Basic Unit Test”

15. Test - 15 - int expected = 4; // Header int result = Calculator.Add(2, 2); //Body Assert.AreEqual(expected, result); //Footer

16. FAIL - 16 -

17. Implement - 17 - public static int Add(int number1, int number2) { return number1 + number2; }

18. Test - 18 -

19. Iterate - 19 -

20. Try It ! - 20 -

21. Write once, run often - 21 - Write tests once Keep them somewhere sensible Run frequently (one click) No human input Machine-parsable output

22. When should I use TDD - 22 - Always Write tests for anything you feel that might break Design of production code should always be test- driven No need to write tests for APIs you don’t own …

23. Two fundamental TDD rules (Kent Beck) - 23 - Never write a single line of code unless you have a failing automated test. Eliminate duplication

24. Refactoring improves design - 24 - “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure” Martin Fowler

25. Question ? 25

26. - 26 - Books

27. 27 https://plus.google.com/u/0/102628787365618084989 http://ch.linkedin.com/in/cuvaalex @cuvaalex (twitter) http://agile-alexcuva.blogspot.chhttp://agile-alexcuva.blogspot.ch (blog) http://www.slideshare.net/GToronto management30.commanagement30.com (book)