Your SlideShare is downloading. ×
0
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Los diez mandamientos de TDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Los diez mandamientos de TDD

1,129

Published on

Charla sobre TDD en el Scrum Bolivian Day

Charla sobre TDD en el Scrum Bolivian Day

1 Comment
0 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
  • Be the first to like this

No Downloads
Views
Total Views
1,129
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 63. Questions?
  • 64. Muchas gracias!info@10pines.com Argentinawww.10Pines.com Tel.: +54 (11) 4780-2460twitter: @10Pines Alem 693, 5B Buenos Aires agile software development & services

×