1. Los Diez Mandamientos de TDD Scrum Bolivia Day Hernán Wilkinson Twitter: @HernanWilkinson Blog: objectmodels.blogspot.com www.10pines.com agile software development & services
2. What is TDD?
3. This is NOT TDD, this is how you do it! So… what is the ESENCE of TDD
4. TDD is not about testing only It is more than that…
5. TDD is about doing incremental problem solving guided by concrete examplesWe are used to incremental development(cycles/iteration), but not incrementaldesign/programming
6. TDD brings testing to development cycle Analisys Testing Program. Design
7. TDD brings testing to development cycle Analisys Testing Design Program.
8. TDD brings testing to development cycle1. Tests are explicit, not implicit anymore2. Tests run automatically, not because a person tests3. Tests bring requirements to live!
9. TDD “SINCERIZA” programmers about testing
10. A programmer that is not a good tester is not a good programmerGood Programmer = Good Tester =
11. TDD is a cultural change… a big one
12. The Commandments1. Management ones2. Technical one A
13. The Management Commandments
14. You shall not expect your developers doTDD because it is God, I mean Good
15. You shall not expect your developers do TDD because it is God, I mean Good 1. It is a Cultural Change!2. Cultural changes do not happen by themselves3. As manager, you have to provide the environment for the change and support it4. … and yes sometimes you have to be tuff, it is part of being a leader5. It is great start doing Pair Programming!
16. You shall provide time to do TDD
17. You shall provide time to do TDD1. YES!! Doing TDD TAKES TIME!!! and more at the beginning… It is a cultural change!2. BUT… the time you “invest” doing TDD gets pay in the mid-term3. Finding a bug running the tests during a regression has no price!… for the rest you have mastercard
18. You shall not send mixed messagesstopping TDD when time looks not enough
19. You shall not send mixed messages stopping TDD when time looks not enough1. The problem is the PLAN… it is a PLAN for God sake!2. If you HAVE TO do it, provide a reasonable explanation, talk to your team!
20. You shall not expect no errors at all
21. You shall not expect no errors at all1. Testing is not a “formal verification technique”2. You can not say anything about what it is not tested… that is why it is important to write the test first3. DO NOT STOP DOING TDD because you got some errors on production4. Use Mutation Testing/Coverage to test your tests!!
22. You shall not expect one hundred percent coverage
23. You shall not expect one hundred percent coverage1. Sometimes it is too costly to automatize certain tests2. Coverage is not a good measure of testing quality3. 100% coverage is impossible when just starting to do TDD
24. You shall not remove the QA team due to TDD
25. You shall not remove the QA team due to TDD1. Because TDD is not about testing only!2. Because TDD does not test UI, user experience, performance, scalability, etc, etc3. TDD helps QA to concentrate on the real and important issues
26. You shall wait for your team to be “test infected”
27. You shall wait for your team to be “test infected”1.Experience is IMPORTANT. Wait yourteam to become expert, it will nothappen in a week2.Do not mix senior programmers withjunior programmers, but semi-seniorprogrammers with both (Pragmaticthinking and learning)
28. The Technical Commandments
29. You shall write the test first
30. You shall write the test first1. Is about incremental design and programming2. Is not about providing a generic implementation with one case3. It is not only about not doing what is not necessary4. If you don’t do it, you will lie to yourself and forget to write some tests5. If you don’t do it, you are just testing6. IT IS THE MOST DIFICULT PART
31. You shall assert in your tests
32. You shall assert in your tests1. Test without assertion is not a test, it is just a mere observation2. If you don’t have an assertion, re- think the whole test or remove it
33. You shall not write many tests and then try to run them
34. You shall not write many tests and then try to run them1. Use a notepad to write the description of the tests that came to your mind2. Wrong design decisions (which is common when not knowing the whole picture) will affect all the tests you wrote3. You have to start feeling comfortable with the “uncertainty”… it is about incremental design/programming
35. You shall not believe that TDD is about unit testing only (with the classical definition of unit testing)
36. You shall not believe that TDD is about unit testing only1. TDD is not only about testing a method or a class2. The more important tests are those that verify a functionality of the system3. Unit Test = Run fast! (less than 100 milliseconds)
37. You shall not name your tests after the HOW but after the WHAT
38. You shall not name your tests after the HOW but after the WHAT1. Wrong name: testAccountBalance
39. You shall verify one case per test
40. You shall verify one case per test1. To keep tests simple2. If a test fails the you know by the test name what it is wrong3. It is difficult to name a test that verifies more than one case smell
41. You shall not test twice the same
42. You shall not test twice the same1. To simplify test maintenance2. To keep consistency
43. You shall keep your tests clean, they are another system
44. You shall keep your tests clean, they are another system1. The tests are another system using yours!2. Test maintenance can get costly if you don’t keep them clean
45. You shall not start testing interfaces, you shall start testing the business model
46. You shall not start testing interfaces, you shall start testing the business model1. Because you have to start with the simplest test possible2. Because you want immediate feedback3. Because is the business model what is important regardless any interface (UI, rest, webservices, etc)
47. You shall not TDD using relational databases
48. You shall not TDD using relational databases1. Relational databases are SLOW (from a testing point of view)2. Relational databases make your development harder3. Relational databases misguide your design4. Relational databases are a solution to a computable problem: persistence5. Test but not TDD using relational database
49. You shall not test using external systems
50. You shall not test using external systems1. A Relational Database is an external system!2. External systems make your test slow3. External systems avoid your test to be in “control of everything”4. External systems create an unnecessary coupling with your tests5. Simulate external systems
51. You shall not mock your wife!
52. You shall not mock your wife!1. There are certain things you should not simulate!2. Do not simulate your business objects3. Only simulate what is out of your system’s reach4. If scenarios are difficult to create, create scenarios factories!5. Objects collaborate, they don’t live alone by themselves
53. You shall understand that TDD does not imply good design
54. You shall understand that TDD does not imply good design1. Good designs are made by good designers2. TDD implies less couple designs but not good ones3. TDD does not imply not to think!4. TDD does not imply not to use good design techniques or rules
55. You shall not worry about performance at the beginning
56. You shall not worry about performance at the beginning1. You shall not worry about performance, persistence, scalability, etc. (the computational problems)2. You shall worry about modeling the business first!
57. You shall love testing as much as programming
58. You shall love testing as much as programming1. Because as programmers, we always test We do it implicitly We do it in our heads2. Testing is part of development3. GOOD PROGRAMMER = GOOD TESTER
59. And now …(Nota: El Papa es Argentino… mais Deus é brasileiro - Dilma dixit)
60. Los Diez Mandamientos1. Amarás TDD sobre todas las cosas2. No usarás el nombre de TDD en vano3. Festejarás cuando uses TDD4. Honrarás a tus tests y tus test suites.5. No matarás a QA
61. Los Diez Mandamientos6. No cometerás adulterio con tus programas7. ROBARAS las ideas de los tests de otros8. No mentirás en tus tests9. DESEARAS los tests de otros10.No codiciarás la falta de testing de los otros
62. Enseñamos estos y otros cursos como:• Diseño Avanzado con Objetos I• Diseño Avanzado con Objetos II• Construcción de Soft. con TDD• TDD Avanzado … y más http://www.10pines.com/content/cursosdisponibles
64. Muchas firstname.lastname@example.org Argentinawww.10Pines.com Tel.: +54 (11) 4780-2460twitter: @10Pines Alem 693, 5B Buenos Aires agile software development & services