Charla sobre TDD en el Scrum Bolivian Day

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
examples
We are used to incremental development
(cycles/iteration), but not incremental
design/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
cycle
1. Tests are explicit, not implicit
anymore
2. Tests run automatically, not because
a person tests
3. 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
1. Management ones
2. Technical one
A

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 
1. It is a Cultural Change!
2. Cultural changes do not happen by themselves
3. As manager, you have to provide the
environment for the change and support it
4. … and yes sometimes you have to be tuff, it is
part of being a leader
5. It is great start doing Pair Programming!

16. You shall provide time to do TDD

17. You shall provide time to do TDD
1. 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-term
3. 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
1. 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 all
1. 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 first
3. DO NOT STOP DOING TDD because you got
some errors on production
4. 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
1. Sometimes it is too costly to
automatize certain tests
2. Coverage is not a good measure of
testing quality
3. 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
1. Because TDD is not about testing
only!
2. Because TDD does not test UI, user
experience, performance, scalability,
etc, etc
3. 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 your
team to become expert, it will not
happen in a week
2.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
1. Is about incremental design and programming
2. Is not about providing a generic implementation
with one case
3. It is not only about not doing what is not
necessary
4. If you don’t do it, you will lie to yourself and
forget to write some tests
5. If you don’t do it, you are just testing
6. IT IS THE MOST DIFICULT PART

31. You shall assert in your tests

32. You shall assert in your tests
1. Test without assertion is not a test,
it is just a mere observation
2. 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
1. Use a notepad to write the description of the
tests that came to your mind
2. Wrong design decisions (which is common
when not knowing the whole picture) will affect
all the tests you wrote
3. 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 only
1. TDD is not only about testing a method
or a class
2. The more important tests are those that
verify a functionality of the system
3. 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
1. Wrong name: testAccountBalance

39. You shall verify one case per test

40. You shall verify one case per test
1. To keep tests simple
2. If a test fails the you know by the
test name what it is wrong
3. 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
1. To simplify test maintenance
2. 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
1. 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
model
1. Because you have to start with the
simplest test possible
2. Because you want immediate feedback
3. 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
1. Relational databases are SLOW (from a testing
point of view)
2. Relational databases make your development
harder
3. Relational databases misguide your design
4. Relational databases are a solution to a
computable problem: persistence
5. Test but not TDD using relational database

49. You shall not test using external
systems

50. You shall not test using external
systems
1. A Relational Database is an external
system!
2. External systems make your test slow
3. External systems avoid your test to be in
“control of everything”
4. External systems create an unnecessary
coupling with your tests
5. 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 objects
3. Only simulate what is out of your
system’s reach
4. 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 design
1. Good designs are made by good
designers
2. TDD implies less couple designs but
not good ones
3. 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 beginning
1. 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
programming
1. Because as programmers, we
always test
We do it implicitly
We do it in our heads
2. Testing is part of development
3. GOOD PROGRAMMER = GOOD
TESTER

59. And now …
(Nota: El Papa es Argentino… mais Deus é brasileiro -
Dilma dixit)

60. Los Diez Mandamientos
1. Amarás TDD sobre todas las cosas
2. No usarás el nombre de TDD en vano
3. Festejarás cuando uses TDD
4. Honrarás a tus tests y tus test suites.
5. No matarás a QA

61. Los Diez Mandamientos
6. No cometerás adulterio con tus
programas
7. ROBARAS las ideas de los tests de otros
8. No mentirás en tus tests
9. DESEARAS los tests de otros
10.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 Argentina
www.10Pines.com
Tel.: +54 (11) 4780-2460
twitter: @10Pines Alem 693, 5B
Buenos Aires
agile software development & services