Your SlideShare is downloading. ×
The Ten Commandments of TDD Hernán Wilkinson Agile 2011
<ul><li>What is TDD? </li></ul>
<ul><li>This is NOT TDD, this is how you do it! </li></ul>So… what is the ESENCE of TDD
<ul><li>TDD is not about testing only </li></ul><ul><li>It is more than that… </li></ul>
<ul><li>TDD is about doing  incremental   problem solving  guided by  concrete examples </li></ul><ul><li>We are use to in...
<ul><li>TDD brings testing to development cycle </li></ul>Analisys Design Program. Testing
<ul><li>TDD brings testing to development cycle </li></ul>Analisys Design Program. Testing
<ul><li>TDD brings testing to development cycle </li></ul><ul><li>Tests are explicit, not implicit anymore </li></ul><ul><...
<ul><li>TDD SINCERIZA programmers about testing </li></ul>
<ul><li>A programmer that is not a good tester is not a good programmer </li></ul><ul><li>Good Programmer = Good Tester </...
<ul><li>TDD is a cultural change… a big one </li></ul>
<ul><li>The Commandments </li></ul><ul><li>Management ones </li></ul><ul><li>Technical one </li></ul><ul><ul><li>About tes...
<ul><li>The Management Commandments </li></ul>
<ul><li>You shall not expect your developers do TDD because it is God, I mean Good   </li></ul>
<ul><li>You shall not expect your developers do TDD because it is God, I mean Good   </li></ul><ul><li>It is a Cultural C...
<ul><li>You shall provide time to do TDD </li></ul>
<ul><li>You shall provide time to do TDD </li></ul><ul><li>YES!! Doing TDD TAKES TIME!!!  and more at the beginning… It is...
<ul><li>You shall not send mixed messages stopping TDD when time looks not enough </li></ul>
<ul><li>You shall not send mixed messages stopping TDD when time looks not enough </li></ul><ul><li>The problem is the PLA...
<ul><li>You shall not expect no errors at all </li></ul>
<ul><li>You shall not expect no errors at all </li></ul><ul><li>Testing is not a “formal verification technique” </li></ul...
<ul><li>You shall not expect one hundred percent coverage </li></ul>
<ul><li>You shall not expect one hundred percent coverage </li></ul><ul><li>Sometimes it is too costly to automatize certa...
<ul><li>You shall not remove the QA team due to TDD </li></ul>
<ul><li>You shall not remove the QA team due to TDD </li></ul><ul><li>Because TDD is not about testing only! </li></ul><ul...
<ul><li>You shall wait for your team to be “test infected” </li></ul>
<ul><li>You shall wait for your team to be “test infected” </li></ul><ul><li>Experience is IMPORTANT. Wait your team to be...
<ul><li>The Technical Commandments </li></ul>
<ul><li>You shall write the test first </li></ul>
<ul><li>You shall write the test first </li></ul><ul><li>Is about incremental design and programming </li></ul><ul><li>Is ...
<ul><li>You shall assert in your tests </li></ul>
<ul><li>You shall assert in your tests </li></ul><ul><li>Test without assertion is not a test, it is just a mere observati...
<ul><li>You shall not write many tests and then try to run them </li></ul>
<ul><li>You shall not write many tests and then try to run them </li></ul><ul><li>Use a notepad to write the description o...
<ul><li>You shall not believe that TDD is about unit testing only  </li></ul><ul><li>(with classical definition of unit te...
<ul><li>You shall not believe that TDD is about unit testing only  </li></ul><ul><li>TDD is not only about testing a metho...
<ul><li>You shall not name your tests after the HOW but after the WHAT </li></ul>
<ul><li>You shall not name your tests after the HOW but after the WHAT </li></ul><ul><li>Wrong name: testAccountBalance </...
<ul><li>You shall verify one case per test </li></ul>
<ul><li>You shall verify one case per test </li></ul><ul><li>To keep tests simple  </li></ul><ul><li>If a test fails the y...
<ul><li>You shall not test twice the same </li></ul>
<ul><li>You shall not test twice the same </li></ul><ul><li>To simplify test maintenance </li></ul><ul><li>To keep consist...
<ul><li>You shall keep your tests clean, they are another system </li></ul>
<ul><li>You shall keep your tests clean, they are another system </li></ul><ul><li>The tests are another system using your...
<ul><li>You shall not start testing interfaces, you shall start testing the business model </li></ul>
<ul><li>You shall not start testing interfaces, you shall start testing the business model </li></ul><ul><li>Because you h...
<ul><li>You shall not TDD using relational databases </li></ul>
<ul><li>You shall not TDD using relational databases </li></ul><ul><li>Relational databases are SLOW (from a testing point...
<ul><li>You shall not test using external systems </li></ul>
<ul><li>You shall not test using external systems </li></ul><ul><li>A Relational Database is an external system! </li></ul...
<ul><li>You shall not mock your wife! </li></ul>
<ul><li>You shall not mock your wife! </li></ul><ul><li>There are certain things you should not simulate! </li></ul><ul><l...
<ul><li>You shall understand that TDD does not imply good design </li></ul>
<ul><li>You shall understand that TDD does not imply good design </li></ul><ul><li>Good designs are made by good designers...
<ul><li>You shall not worry about performance at the beginning </li></ul>
<ul><li>You shall not worry about performance at the beginning </li></ul><ul><li>You shall not worry about performance, pe...
<ul><li>You shall love testing as much as programming </li></ul>
<ul><li>You shall love testing as much as programming </li></ul><ul><li>Because as programmers, we always test We do it im...
<ul><li>And now the joke… </li></ul>
<ul><li>The ten commandments </li></ul><ul><li>I am TDD your Development Technique; you shall not have strange techniques ...
<ul><li>The ten commandments </li></ul><ul><li>You shall not commit adultery forgetting to write the test first </li></ul>...
<ul><li>We teach this and other important design aspects in our courses </li></ul><ul><li>Advance Design with OO : Nov 14 ...
Questions?
<ul><li>Muchas gracias! </li></ul>[email_address] www.10Pines.com twitter: @10Pines Argentina Tel.:  +54 (11) 4780-2460 Pa...
Upcoming SlideShare
Loading in...5
×

The ten commandments of TDD

816

Published on

Published in: Technology, Education
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
816
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "The ten commandments of TDD"

  1. 1. The Ten Commandments of TDD Hernán Wilkinson Agile 2011
  2. 2. <ul><li>What is TDD? </li></ul>
  3. 3. <ul><li>This is NOT TDD, this is how you do it! </li></ul>So… what is the ESENCE of TDD
  4. 4. <ul><li>TDD is not about testing only </li></ul><ul><li>It is more than that… </li></ul>
  5. 5. <ul><li>TDD is about doing incremental problem solving guided by concrete examples </li></ul><ul><li>We are use to incremental development (cycles/iteration), but not incremental design/programming </li></ul>
  6. 6. <ul><li>TDD brings testing to development cycle </li></ul>Analisys Design Program. Testing
  7. 7. <ul><li>TDD brings testing to development cycle </li></ul>Analisys Design Program. Testing
  8. 8. <ul><li>TDD brings testing to development cycle </li></ul><ul><li>Tests are explicit, not implicit anymore </li></ul><ul><li>Tests run automatically, not because the a person test </li></ul><ul><li>Tests bring requirements to live! </li></ul>
  9. 9. <ul><li>TDD SINCERIZA programmers about testing </li></ul>
  10. 10. <ul><li>A programmer that is not a good tester is not a good programmer </li></ul><ul><li>Good Programmer = Good Tester </li></ul>=
  11. 11. <ul><li>TDD is a cultural change… a big one </li></ul>
  12. 12. <ul><li>The Commandments </li></ul><ul><li>Management ones </li></ul><ul><li>Technical one </li></ul><ul><ul><li>About testing </li></ul></ul><ul><ul><li>About design </li></ul></ul><ul><li>(Sadly, they are more than ten…) </li></ul>
  13. 13. <ul><li>The Management Commandments </li></ul>
  14. 14. <ul><li>You shall not expect your developers do TDD because it is God, I mean Good  </li></ul>
  15. 15. <ul><li>You shall not expect your developers do TDD because it is God, I mean Good  </li></ul><ul><li>It is a Cultural Change! </li></ul><ul><li>Cultural changes do not happen by themselves </li></ul><ul><li>As manager, you have to provide the environment for the change and support it </li></ul><ul><li>… and yes sometimes you have to be tuff, it is part of being a leader </li></ul><ul><li>It is great start doing Pair Programming! </li></ul>
  16. 16. <ul><li>You shall provide time to do TDD </li></ul>
  17. 17. <ul><li>You shall provide time to do TDD </li></ul><ul><li>YES!! Doing TDD TAKES TIME!!! and more at the beginning… It is a cultural change! </li></ul><ul><li>BUT… the time you “invest” doing TDD gets pay in the mid-term </li></ul><ul><li>Finding a bug running the tests during a regression has no price!… for the rest you have mastercard </li></ul>
  18. 18. <ul><li>You shall not send mixed messages stopping TDD when time looks not enough </li></ul>
  19. 19. <ul><li>You shall not send mixed messages stopping TDD when time looks not enough </li></ul><ul><li>The problem is the PLAN… it is a PLAN for God sake! </li></ul><ul><li>If you HAVE TO do it, provide a reasonable explanation, talk to your team! </li></ul>
  20. 20. <ul><li>You shall not expect no errors at all </li></ul>
  21. 21. <ul><li>You shall not expect no errors at all </li></ul><ul><li>Testing is not a “formal verification technique” </li></ul><ul><li>You can not say anything about what it is not tested… that is why it is important to write the test first </li></ul><ul><li>DO NOT STOP DOING TDD because you got some errors on production </li></ul><ul><li>Use Mutation Testing/Coverage to test your tests!! </li></ul>
  22. 22. <ul><li>You shall not expect one hundred percent coverage </li></ul>
  23. 23. <ul><li>You shall not expect one hundred percent coverage </li></ul><ul><li>Sometimes it is too costly to automatize certain tests </li></ul><ul><li>Coverage is not a good measure of testing quality </li></ul><ul><li>100% coverage is impossible when just starting to do TDD </li></ul>
  24. 24. <ul><li>You shall not remove the QA team due to TDD </li></ul>
  25. 25. <ul><li>You shall not remove the QA team due to TDD </li></ul><ul><li>Because TDD is not about testing only! </li></ul><ul><li>Because TDD does not test UI, user experience, performance, scalability, etc, etc </li></ul><ul><li>TDD helps QA to concentrate on the real and important issues </li></ul>
  26. 26. <ul><li>You shall wait for your team to be “test infected” </li></ul>
  27. 27. <ul><li>You shall wait for your team to be “test infected” </li></ul><ul><li>Experience is IMPORTANT. Wait your team to become expert, it will not happen in a week </li></ul><ul><li>Do not mix senior programmers with junior programmers, but semi-senior programmers with both (Pragmatic thinking and learning) </li></ul>
  28. 28. <ul><li>The Technical Commandments </li></ul>
  29. 29. <ul><li>You shall write the test first </li></ul>
  30. 30. <ul><li>You shall write the test first </li></ul><ul><li>Is about incremental design and programming </li></ul><ul><li>Is not about providing a generic implementation with one case </li></ul><ul><li>It is not only about not doing what is not necessary </li></ul><ul><li>If you don’t do it, you will lie to yourself and forget to write some tests </li></ul><ul><li>If you don’t do it, you are just testing </li></ul><ul><li>IT IS THE MOST DIFICULT PART </li></ul>
  31. 31. <ul><li>You shall assert in your tests </li></ul>
  32. 32. <ul><li>You shall assert in your tests </li></ul><ul><li>Test without assertion is not a test, it is just a mere observation </li></ul><ul><li>If you don’t have an assertion, re-think the whole test or remove it </li></ul>
  33. 33. <ul><li>You shall not write many tests and then try to run them </li></ul>
  34. 34. <ul><li>You shall not write many tests and then try to run them </li></ul><ul><li>Use a notepad to write the description of the tests that came to your mind </li></ul><ul><li>Wrong design decisions (which is common when not knowing the whole picture) will affect all the tests you wrote </li></ul><ul><li>You have to start feeling comfortable with the “uncertainty”… it is about incremental design/programming </li></ul>
  35. 35. <ul><li>You shall not believe that TDD is about unit testing only </li></ul><ul><li>(with classical definition of unit testing) </li></ul>
  36. 36. <ul><li>You shall not believe that TDD is about unit testing only </li></ul><ul><li>TDD is not only about testing a method or a class </li></ul><ul><li>The more important tests are those that verify a functionality of the system </li></ul><ul><li>Unit Test = Run fast! (less than 100 milliseconds) </li></ul>
  37. 37. <ul><li>You shall not name your tests after the HOW but after the WHAT </li></ul>
  38. 38. <ul><li>You shall not name your tests after the HOW but after the WHAT </li></ul><ul><li>Wrong name: testAccountBalance </li></ul><ul><ul><li>Too generic, it is not a concrete example </li></ul></ul><ul><li>Good name: testGivenAnAccountWithoutTransactionsWhenAskedForItsBalanceThenItShouldReturnCero It is a concrete example </li></ul><ul><li>Test names are LONG! and they should be </li></ul>
  39. 39. <ul><li>You shall verify one case per test </li></ul>
  40. 40. <ul><li>You shall verify one case per test </li></ul><ul><li>To keep tests simple </li></ul><ul><li>If a test fails the you know by the test name what it is wrong </li></ul><ul><li>It is difficult to name a test that verifies more than one case  smell </li></ul>
  41. 41. <ul><li>You shall not test twice the same </li></ul>
  42. 42. <ul><li>You shall not test twice the same </li></ul><ul><li>To simplify test maintenance </li></ul><ul><li>To keep consistency </li></ul>
  43. 43. <ul><li>You shall keep your tests clean, they are another system </li></ul>
  44. 44. <ul><li>You shall keep your tests clean, they are another system </li></ul><ul><li>The tests are another system using yours! </li></ul><ul><li>Test maintenance can get costly if you don’t keep them clean </li></ul>
  45. 45. <ul><li>You shall not start testing interfaces, you shall start testing the business model </li></ul>
  46. 46. <ul><li>You shall not start testing interfaces, you shall start testing the business model </li></ul><ul><li>Because you have to start with the simplest test possible </li></ul><ul><li>Because you want immediate feedback </li></ul><ul><li>Because is the business model what is important regardless any interface (UI, rest, webservices, etc) </li></ul>
  47. 47. <ul><li>You shall not TDD using relational databases </li></ul>
  48. 48. <ul><li>You shall not TDD using relational databases </li></ul><ul><li>Relational databases are SLOW (from a testing point of view) </li></ul><ul><li>Relational databases make your development harder </li></ul><ul><li>Relational databases misguide your design </li></ul><ul><li>Relational databases are a solution to a computable problem: persistence </li></ul><ul><li>Test but not TDD using relational database </li></ul>
  49. 49. <ul><li>You shall not test using external systems </li></ul>
  50. 50. <ul><li>You shall not test using external systems </li></ul><ul><li>A Relational Database is an external system! </li></ul><ul><li>External systems make your test slow </li></ul><ul><li>External systems avoid your test to be in “control of everything” </li></ul><ul><li>External systems create an unnecessary coupling with your tests </li></ul><ul><li>Simulate external systems </li></ul>
  51. 51. <ul><li>You shall not mock your wife! </li></ul>
  52. 52. <ul><li>You shall not mock your wife! </li></ul><ul><li>There are certain things you should not simulate! </li></ul><ul><li>Do not simulate your business objects </li></ul><ul><li>Only simulate what is out of your system’s reach </li></ul><ul><li>If scenarios are difficult to create, create scenarios factories! </li></ul><ul><li>Object collaborate, they don’t live alone by themselves </li></ul>
  53. 53. <ul><li>You shall understand that TDD does not imply good design </li></ul>
  54. 54. <ul><li>You shall understand that TDD does not imply good design </li></ul><ul><li>Good designs are made by good designers </li></ul><ul><li>TDD implies less couple designs but not good ones </li></ul><ul><li>TDD does not imply not to think! </li></ul><ul><li>TDD does not imply not to use good design techniques or rules </li></ul>
  55. 55. <ul><li>You shall not worry about performance at the beginning </li></ul>
  56. 56. <ul><li>You shall not worry about performance at the beginning </li></ul><ul><li>You shall not worry about performance, persistence, scalability, etc. (the computational problems) </li></ul><ul><li>You shall worry about modeling the business first! </li></ul>
  57. 57. <ul><li>You shall love testing as much as programming </li></ul>
  58. 58. <ul><li>You shall love testing as much as programming </li></ul><ul><li>Because as programmers, we always test We do it implicitly We do it in our heads </li></ul><ul><li>Testing is part of development </li></ul><ul><li>GOOD PROGRAMMER = GOOD TESTER </li></ul>
  59. 59. <ul><li>And now the joke… </li></ul>
  60. 60. <ul><li>The ten commandments </li></ul><ul><li>I am TDD your Development Technique; you shall not have strange techniques before me. </li></ul><ul><li>You shall not take the name of TDD, your Development Technique, in vain. </li></ul><ul><li>Remember to keep holy all days to TDD </li></ul><ul><li>Honor your tests and your programs. </li></ul><ul><li>You shall not kill QA </li></ul>
  61. 61. <ul><li>The ten commandments </li></ul><ul><li>You shall not commit adultery forgetting to write the test first </li></ul><ul><li>You SHALL steal other test ideas </li></ul><ul><li>You shall not bear false witness against TDD if you have not try it. </li></ul><ul><li>You SHALL covet your neighbor's tests. </li></ul><ul><li>You shall not covet your neighbor's lack of testing. </li></ul>
  62. 62. <ul><li>We teach this and other important design aspects in our courses </li></ul><ul><li>Advance Design with OO : Nov 14 th </li></ul><ul><li>TDD : Oct 25 th , Nov 22 nd </li></ul><ul><li>Check them out at: </li></ul><ul><li>http://www.10pines.com/content/cursosdisponibles </li></ul>
  63. 63. Questions?
  64. 64. <ul><li>Muchas gracias! </li></ul>[email_address] www.10Pines.com twitter: @10Pines Argentina Tel.: +54 (11) 4780-2460 Paraguay 523, 7N Buenos Aires

×