The document discusses the ten commandments of test-driven development (TDD). It provides commandments for both management and technical aspects of TDD. The management commandments include allowing time for TDD, not stopping it due to errors or time constraints, and waiting for developers to become experienced with testing. The technical commandments include writing tests before code, naming tests descriptively, testing one case per test, and focusing initially on the business model rather than interfaces. The document emphasizes that TDD is a cultural change that improves testing and design.

1. The Ten Commandments of TDD Hernán Wilkinson Agile 2011

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 examples We are use to incremental development (cycles/iteration), but not incremental design/programming

6. TDD brings testing to development cycle Analisys Design Program. Testing

7. TDD brings testing to development cycle Analisys Design Program. Testing

8. TDD brings testing to development cycle Tests are explicit, not implicit anymore Tests run automatically, not because the a person test Tests bring requirements to live!

9. TDD SINCERIZA programmers about testing

10. A programmer that is not a good tester is not a good programmer Good Programmer = Good Tester =

11. TDD is a cultural change… a big one

12. The Commandments Management ones Technical one About testing About design (Sadly, they are more than ten…)

13. The Management Commandments

14. You shall not expect your developers do TDD because it is God, I mean Good 

15. You shall not expect your developers do TDD because it is God, I mean Good  It is a Cultural Change! Cultural changes do not happen by themselves As manager, you have to provide the environment for the change and support it … and yes sometimes you have to be tuff, it is part of being a leader It is great start doing Pair Programming!

16. You shall provide time to do TDD

17. You shall provide time to do TDD YES!! Doing TDD TAKES TIME!!! and more at the beginning… It is a cultural change! BUT… the time you “invest” doing TDD gets pay in the mid-term Finding a bug running the tests during a regression has no price!… for the rest you have mastercard

18. You shall not send mixed messages stopping TDD when time looks not enough

19. You shall not send mixed messages stopping TDD when time looks not enough The problem is the PLAN… it is a PLAN for God sake! 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 all Testing is not a “formal verification technique” You can not say anything about what it is not tested… that is why it is important to write the test first DO NOT STOP DOING TDD because you got some errors on production 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 coverage Sometimes it is too costly to automatize certain tests Coverage is not a good measure of testing quality 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 TDD Because TDD is not about testing only! Because TDD does not test UI, user experience, performance, scalability, etc, etc 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” Experience is IMPORTANT. Wait your team to become expert, it will not happen in a week Do not mix senior programmers with junior programmers, but semi-senior programmers with both (Pragmatic thinking and learning)

28. The Technical Commandments

29. You shall write the test first

30. You shall write the test first Is about incremental design and programming Is not about providing a generic implementation with one case It is not only about not doing what is not necessary If you don’t do it, you will lie to yourself and forget to write some tests If you don’t do it, you are just testing IT IS THE MOST DIFICULT PART

31. You shall assert in your tests

32. You shall assert in your tests Test without assertion is not a test, it is just a mere observation 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 them Use a notepad to write the description of the tests that came to your mind Wrong design decisions (which is common when not knowing the whole picture) will affect all the tests you wrote 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 classical definition of unit testing)

36. You shall not believe that TDD is about unit testing only TDD is not only about testing a method or a class The more important tests are those that verify a functionality of the system 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 WHAT Wrong name: testAccountBalance Too generic, it is not a concrete example Good name: testGivenAnAccountWithoutTransactionsWhenAskedForItsBalanceThenItShouldReturnCero It is a concrete example Test names are LONG! and they should be

39. You shall verify one case per test

40. You shall verify one case per test To keep tests simple If a test fails the you know by the test name what it is wrong 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 same To simplify test maintenance To keep consistency

43. You shall keep your tests clean, they are another system

44. You shall keep your tests clean, they are another system The tests are another system using yours! 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 model Because you have to start with the simplest test possible Because you want immediate feedback 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 databases Relational databases are SLOW (from a testing point of view) Relational databases make your development harder Relational databases misguide your design Relational databases are a solution to a computable problem: persistence Test but not TDD using relational database

49. You shall not test using external systems

50. You shall not test using external systems A Relational Database is an external system! External systems make your test slow External systems avoid your test to be in “control of everything” External systems create an unnecessary coupling with your tests Simulate external systems

51. You shall not mock your wife!

52. You shall not mock your wife! There are certain things you should not simulate! Do not simulate your business objects Only simulate what is out of your system’s reach If scenarios are difficult to create, create scenarios factories! Object 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 design Good designs are made by good designers TDD implies less couple designs but not good ones TDD does not imply not to think! 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 beginning You shall not worry about performance, persistence, scalability, etc. (the computational problems) 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 programming Because as programmers, we always test We do it implicitly We do it in our heads Testing is part of development GOOD PROGRAMMER = GOOD TESTER

59. And now the joke…

60. The ten commandments I am TDD your Development Technique; you shall not have strange techniques before me. You shall not take the name of TDD, your Development Technique, in vain. Remember to keep holy all days to TDD Honor your tests and your programs. You shall not kill QA

61. The ten commandments You shall not commit adultery forgetting to write the test first You SHALL steal other test ideas You shall not bear false witness against TDD if you have not try it. You SHALL covet your neighbor's tests. You shall not covet your neighbor's lack of testing.

62. We teach this and other important design aspects in our courses Advance Design with OO : Nov 14 th TDD : Oct 25 th , Nov 22 nd Check them out at: http://www.10pines.com/content/cursosdisponibles

63. Questions?

64. Muchas gracias! [email_address] www.10Pines.com twitter: @10Pines Argentina Tel.: +54 (11) 4780-2460 Paraguay 523, 7N Buenos Aires