Los Diez Mandamientos de           TDD     Scrum Bolivia Day       Hernán Wilkinson               Twitter: @HernanWilkinso...
What is TDD?
This is NOT TDD, this is how you do it!   So… what is the ESENCE of TDD
TDD is not about testing only   It is more than that…
TDD is about doing incremental problem solving guided by concrete             examplesWe are used to incremental developme...
TDD brings testing to development                cycle               Analisys                                   Testing   ...
TDD brings testing to development                cycle                     Analisys           Testing              Design ...
TDD brings testing to development                  cycle1. Tests are explicit, not implicit   anymore2. Tests run automati...
TDD “SINCERIZA” programmers about              testing
A programmer that is not a good tester      is not a good programmerGood Programmer = Good Tester                 =
TDD is a cultural change… a big one
The Commandments1. Management ones2. Technical one A
The Management Commandments
You shall not expect your developers doTDD because it is God, I mean Good 
You shall not expect your developers   do TDD because it is God, I mean                 Good 1. It is a Cultural Change!2...
You shall provide time to do TDD
You shall provide time to do TDD1. YES!! Doing TDD TAKES TIME!!!   and more at the beginning… It is a cultural   change!2....
You shall not send  mixed messagesstopping TDD when   time looks not      enough
You shall not send mixed messages    stopping TDD when time looks not                  enough1. The problem is the PLAN… i...
You shall not expect no errors at all
You shall not expect no errors at all1. Testing is not a “formal verification technique”2. You can not say anything about ...
You shall not expect one hundred        percent coverage
You shall not expect one hundred            percent coverage1. Sometimes it is too costly to   automatize certain tests2. ...
You shall not remove the QA team due                to TDD
You shall not remove the QA team due                 to TDD1. Because TDD is not about testing   only!2. Because TDD does ...
You shall wait for your team to be “test                infected”
You shall wait for your team to be “test                infected”1.Experience is IMPORTANT. Wait yourteam to become expert...
The Technical Commandments
You shall write the test          first
You shall write the test first1. Is about incremental design and programming2. Is not about providing a generic implementa...
You shall assert in your tests
You shall assert in your tests1. Test without assertion is not a test,   it is just a mere observation2. If you don’t have...
You shall not write many tests and      then try to run them
You shall not write many tests and           then try to run them1. Use a notepad to write the description of the   tests ...
You shall not believe that TDD is about           unit testing only (with the classical definition of unit               t...
You shall not believe that TDD is about            unit testing only1. TDD is not only about testing a method   or a class...
You shall not name your tests after the      HOW but after the WHAT
You shall not name your tests after the        HOW but after the WHAT1. Wrong name: testAccountBalance
You shall verify one case per test
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 wro...
You shall not test twice the same
You shall not test twice the same1. To simplify test maintenance2. To keep consistency
You shall keep your tests clean, they         are another system
You shall keep your tests clean, they           are another system1. The tests are another system using   yours!2. Test ma...
You shall not start testing interfaces, you shall start testing the business                model
You shall not start testing interfaces,    you shall start testing the business                   model1. Because you have...
You shall not TDD using relational            databases
You shall not TDD using relational                 databases1. Relational databases are SLOW (from a testing   point of vi...
You shall not test using external            systems
You shall not test using external                  systems1. A Relational Database is an external   system!2. External sys...
You shall not mock your wife!
You shall not mock your wife!1. There are certain things you should not   simulate!2. Do not simulate your business object...
You shall understand that TDD does      not imply good design
You shall understand that TDD does          not imply good design1. Good designs are made by good   designers2. TDD implie...
You shall not worry about performance           at the beginning
You shall not worry about performance             at the beginning1. You shall not worry about   performance, persistence,...
You shall love testing as much as           programming
You shall love testing as much as                programming1. Because as programmers, we   always test   We do it implici...
And now …(Nota: El Papa es Argentino… mais Deus é brasileiro -                     Dilma dixit)
Los Diez Mandamientos1.   Amarás TDD sobre todas las cosas2.   No usarás el nombre de TDD en vano3.   Festejarás cuando us...
Los Diez Mandamientos6. No cometerás adulterio con tus   programas7. ROBARAS las ideas de los tests de otros8. No mentirás...
Enseñamos estos y otros cursos como:• Diseño Avanzado con Objetos I• Diseño Avanzado con Objetos II• Construcción de Soft....
Questions?
Muchas gracias!info@10pines.com        Argentinawww.10Pines.com                        Tel.: +54 (11) 4780-2460twitter: @1...
Upcoming SlideShare
Loading in...5
×

Los diez mandamientos de TDD

1,311

Published on

Charla sobre TDD en el Scrum Bolivian Day

1 Comment
3 Likes
Statistics
Notes
  • Muy buena presentación, la disfruté. Reemplazar 'tuff' por 'tough'
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,311
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
12
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Los diez mandamientos de TDD

  1. 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. 2. What is TDD?
  3. 3. This is NOT TDD, this is how you do it! So… what is the ESENCE of TDD
  4. 4. TDD is not about testing only It is more than that…
  5. 5. TDD is about doing incremental problem solving guided by concrete examplesWe are used to incremental development(cycles/iteration), but not incrementaldesign/programming
  6. 6. TDD brings testing to development cycle Analisys Testing Program. Design
  7. 7. TDD brings testing to development cycle Analisys Testing Design Program.
  8. 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. 9. TDD “SINCERIZA” programmers about testing
  10. 10. A programmer that is not a good tester is not a good programmerGood Programmer = Good Tester =
  11. 11. TDD is a cultural change… a big one
  12. 12. The Commandments1. Management ones2. Technical one A
  13. 13. The Management Commandments
  14. 14. You shall not expect your developers doTDD because it is God, I mean Good 
  15. 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. 16. You shall provide time to do TDD
  17. 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. 18. You shall not send mixed messagesstopping TDD when time looks not enough
  19. 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. 20. You shall not expect no errors at all
  21. 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. 22. You shall not expect one hundred percent coverage
  23. 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. 24. You shall not remove the QA team due to TDD
  25. 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. 26. You shall wait for your team to be “test infected”
  27. 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. 28. The Technical Commandments
  29. 29. You shall write the test first
  30. 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. 31. You shall assert in your tests
  32. 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. 33. You shall not write many tests and then try to run them
  34. 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. 35. You shall not believe that TDD is about unit testing only (with the classical definition of unit testing)
  36. 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. 37. You shall not name your tests after the HOW but after the WHAT
  38. 38. You shall not name your tests after the HOW but after the WHAT1. Wrong name: testAccountBalance
  39. 39. You shall verify one case per test
  40. 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. 41. You shall not test twice the same
  42. 42. You shall not test twice the same1. To simplify test maintenance2. To keep consistency
  43. 43. You shall keep your tests clean, they are another system
  44. 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. 45. You shall not start testing interfaces, you shall start testing the business model
  46. 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. 47. You shall not TDD using relational databases
  48. 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. 49. You shall not test using external systems
  50. 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. 51. You shall not mock your wife!
  52. 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. 53. You shall understand that TDD does not imply good design
  54. 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. 55. You shall not worry about performance at the beginning
  56. 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. 57. You shall love testing as much as programming
  58. 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. 59. And now …(Nota: El Papa es Argentino… mais Deus é brasileiro - Dilma dixit)
  60. 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. 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. 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
  63. 63. Questions?
  64. 64. Muchas gracias!info@10pines.com Argentinawww.10Pines.com Tel.: +54 (11) 4780-2460twitter: @10Pines Alem 693, 5B Buenos Aires agile software development & services
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×