Seconda serata di introduzione al Test-Driven Development, tenuta in XPeppers a Trento il 24 Ottobre 2012. Nelle slide c'è anche la descrizione del coding dojo sullo string calculator che abbiamo svolto assieme.

1. Test-Driven Development
Pietro Di Bello
pietro.di.bello@xpeppers.com
twitter: @pierodibello
www.xpeppers.com
JUG Trentino Alto-Adige
Ottobre 2012

2. Test-Driven Development
reloaded
Pietro Di Bello
pietro.di.bello@xpeppers.com
twitter: @pierodibello
www.xpeppers.com
JUG Trentino Alto-Adige
Ottobre 2012

3. Che cos’è il TDD?

4. Che cos’è il TDD?
TDD = Test-driven development

5. Che cos’è il TDD?
TDD = Test-driven development
è una tecnica di sviluppo

6. Che cos’è il TDD?
TDD = Test-driven development
è una tecnica di sviluppo
inventata da uno sviluppatore

7. Che cos’è il TDD?
TDD = Test-driven design
è una tecnica di design e di
sviluppo

8. Qual’è l’obbiettivo del TDD?
L’obbiettivo del TDD è scrivere
“codice pulito che funziona”

9. Qual’è l’obbiettivo del TDD?
Clean code
that works
• is out of reach of even
the best programmers,
some of the time,
• and out of reach of most
programmers (like me)
most of the time
-- Kent Beck

10. Che cos’è il TDD?
TDD = Test-driven development
guidata dalla scrittura di test
automatici unitari

11. Che cos’è il TDD?
Test automatici e unitari
automatici = le verifiche
le fa la macchina al posto
mio

12. Che cos’è il TDD?
Test automatici e unitari
unitari = non verifico
l’intero sistema ma una
singola unità (classe,
modulo, funzione)

13. e allora?
Nel TDD si usano i test
automatici per guidare il design
e lo sviluppo del codice

14. Il ritmo del TDD

15. Il ritmo del TDD
Red — Write a little test that doesn't
work, and perhaps doesn't even
compile at first.

16. Il ritmo del TDD
Red — Write a little test that doesn't
work, and perhaps doesn't even
compile at first.
Green — Make the test work quickly,
committing whatever sins necessary in
the process.

17. Il ritmo del TDD
Red — Write a little test that doesn't
work, and perhaps doesn't even
compile at first.
Green — Make the test work quickly,
committing whatever sins necessary in
the process.
Refactor — Eliminate all of the
duplication created in merely
getting the test to work.

18. Write a test
public class AdderTest {
@Test
public void testTwoPlusThree() {
Adder a = new Adder();
assertEquals(5, a.add(2, 3));
}
}

19. Now it compiles
public class AdderTest {
@Test
public void testTwoPlusThree() {
Adder a = new Adder();
assertEquals(5, a.add(2, 3));
}
}
public class Adder {
public int add(int a, int b) { return 0; }
}

20. Red bar!
public class AdderTest {
@Test
public void testTwoPlusThree() {
Adder a = new Adder();
assertEquals(5, a.add(2, 3));
}
}
public class Adder {
public int add(int a, int b) { return 0; }
}
Expected 5, was 0

21. Do the simplest thing
public class AdderTest {
@Test
public void testTwoPlusThree() {
Adder a = new Adder();
assertEquals(5, a.add(2, 3));
}
}
public class Adder {
public int add(int a, int b) { return 5; }
}

22. Refactor
public class AdderTest {
@Test
public void testTwoPlusThree() {
Adder a = new Adder();
assertEquals(5, a.add(2, 3));
}
}
public class Adder {
public int add(int a, int b) { return a
+b; }
}

23. The procedure
1. Write a test
2. Make it compile
Expected 5, was 0
3. Make it pass quickly
4. Refactor to remove duplication

24. The procedure
Red
Refactor Green
Repeat every 2-10 min.

25. Prima un test che fallisce
Red — Write a little test that doesn't
work, and perhaps doesn't even
compile at first.

26. Il codice visto dalla barra rossa
When we write a test, we
imagine the perfect interface for
our operation. We are telling
ourselves a story about how the
operation will look from the
outside. Our story won't always
come true, but it's better to start
from the best-possible
application program interface
(API) and work backward than to
make things complicated, ugly,
and "realistic" from the get-go.
Kent Beck

27. Maialino time... :)
Green — Make the test work quickly,
committing whatever sins necessary in
the process.

28. Paga per i tuoi debiti...
Refactor — Eliminate all of the
duplication created in merely getting
the test to work.

29. Qual’è l’essenza del TDD?
L’essenza del TDD è “sapere sempre
quale sarà il prossimo passo”

30. Qual’è l’essenza del TDD?
L’essenza del TDD è “sapere sempre
quale sarà il prossimo passo”
Avere chiara la strada

31. L’essenza del TDD
Meno stress

32. L’essenza del TDD
Meno stress
• Progresso misurabile e verificabile
• Copertura di test
• Controllo dello scope
• Riduzione del bug rate

33. L’essenza del TDD
Progresso misurabile e verificabile

34. L’essenza del TDD
A piccoli passi

35. L’essenza del TDD
Copertura di test

36. L’essenza del TDD
Controllo dello scope funzionale

37. Uso della TODO list
• Utile per gestire la complessità
• elencare i diversi aspetti del problema
• NON si elencano i test da implementare
• non è TDD
• Riduce lo stress
• Bussola per farci capire a che punto siamo
e non ci perdere la strada
• Se mi viene in mente qualcosa la scrivo
nella todolist e continuo sulla mia strada
senza perdere focus

38. Quando usare il TDD è difficile?
• Quando si sviluppare codice multithreaded
• Quando si lavora su codice legacy
• Quando si padroneggia poco il linguaggio
di programmazione usato

39. Cosa non è uno unit-test?
A test is not a unit test if:
• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your
other unit tests
• You have to do special things to your
environment (such as editing config files) to
run it.
Michael Feathers (“A Set of Unit Testing Rules”)

40. The Three Rules Of TDD
• You are not allowed to write any production
code unless it is to make a failing unit test pass.
• You are not allowed to write any more of a unit
test than is sufficient to fail; and compilation
failures are failures.
• You are not allowed to write any more
production code than is sufficient to pass the
one failing unit test.
Robert “Uncle Bob” Martin (“The Three Laws of TDD”)

41. Debugging
Sucks
Testing
Rocks

43. Coding Dojo
String Calculator
• by Roy Osherove
• (http://osherove.com/tdd-kata-1)

44. StringCalculator Kata
• Create a simple String calculator with a method
• int Add(string numbers)
• The method can take zero, one or two numbers,
and will return their sum
• for example “” or “1” or “1,2”
• for an empty string it will return 0
Start with the simplest test case of an empty string
and move to one and two numbers

45. StringCalculator Kata
• Remember to solve things as simply as
possible so that you force yourself to write
tests you did not think about
• Remember to refactor after each passing
test

46. StringCalculator Kata
Allow the Add method to handle an unknown
amount of numbers

47. StringCalculator Kata
Allow the Add method to handle new lines between
numbers (instead of commas).
• the following input is ok: “1n2,3” (will equal 6)
• the following input is NOT ok: “1,n” (not need
to prove it - just clarifying)

48. StringCalculator Kata
Support different delimiters
to change a delimiter, the beginning of the string will
contain a separate line that looks like this:
“//[delimiter]n[numbers…]”
for example “//;n1;2” should return three where the
default delimiter is ‘;’ .
the first line is optional.
all existing scenarios should still be supported

49. StringCalculator Kata
Calling Add with a negative number will
throw an exception “negatives not allowed” -
and the negative that was passed.
If there are multiple negatives, show all of
them in the exception message

50. StringCalculator Kata
Numbers bigger than 1000 should be ignored.
So adding 2 + 1001 = 2

51. StringCalculator Kata
Delimiters can be of any length with the
following format:
“//[delimiter]n”
For example:
“//[***]n1***2***3” returns 6.

52. StringCalculator Kata
Make sure you can also handle multiple
delimiters with length longer than one char

53. Contacts
• Website www.xpeppers.com
• E-Mail info@xpeppers.com
• Twitter @xpeppers