1. The document describes a TDD workshop presented by several individuals. 2. It discusses TDD techniques like red-green-refactor and emphasizes growing production and test code together rather than writing tests later. 3. The workshop covers TDD principles like writing tests before code, refactoring, and simple design and explores examples like a bank account kata.

1. TDD workshop
Beyond red-green-refactor
@codurance_ES
@ertorser
@bberrycarmen

2. About us ...

3. “...
B
V f …”

4. Thanks ...

5. THANKS ...
@vitemprende @codurance_ES
@flype@tohuerta

7. We are not here for ...

10. TDD do not ... make decisions for yourself

11. TDD is ... a guide

12. TDD is not ... a testing discipline

13. TDD is ... a design discipline

16. Let’s start from the beginning...

17. “Today a usual technique is
to make a program
and then to test it.“

18. The Humble Programmer (1972) - Dijkstra
Argument three is based on the constructive approach to the problem of program
correctness. Today a usual technique is to make a program and then to test it. But:
program testing can be a very effective way to show the presence of bugs, but is
hopelessly inadequate for showing their absence. The only effective way to raise the
confidence level of a program significantly is to give a convincing proof of its
correctness. But one should not first make the program and then prove its correctness,
because then the requirement of providing the proof would only increase the poor
programmer’s burden. On the contrary: the programmer should let correctness proof
and program grow hand in hand. Argument three is essentially based on the following
observation. If one first asks oneself what the structure of a convincing proof would be
and, having found this, then constructs a program satisfying this proof’s requirements,
then these correctness concerns turn out to be a very effective heuristic guidance.

20. PRODUCTION
CODE
TEST
CODE

21. TEST
CODE
PRODUCTION
CODE

22. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR

23. Refactor ?

24. Production code & Test code

25. 4 RULES OF SIMPLE DESIGN

26. “Design for the future.
Change is expensive.
Make it cheap by anticipating it.”

27. 4 RULES OF SIMPLE DESIGN
● Pass all the tests
● Reveal intention
● No duplication
● Fewer elements

28. 4 RULES OF SIMPLE DESIGN
● Pass all the tests
● Reveal intention
● No knowledge duplication
● Fewer elements

29. 4RSD
Clean architecture
C.R.P.
Connascence
S.o.C.
Cohesion
Coupling
P.O.L.A.
D.R.Y.
GoF Patterns
K.I.S.S.
Y.A.G.N.I.
Law of Demeter
S.O.L.I.D.
DDD
Screaming Architecture
IDD

30. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
HUMILITY

31. “Write a test, make it run, make it right.
To make it run,
one is allowed to violate principles of good design.
Making it right means to refactor it.”
Dave Hoover

32. Is this a workshop?

33. Rules

34. DRIVER NAVIGATOR

35. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
DRIVER <-> NAVIGATOR

36. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
$> git commit -m “RED: ... “
$> git commit -m “GREEN: ... “
$> git commit -m “REFACTOR: ... “

37. Arrange
Act
Assert

38. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
IN TEST METHODMOVE TO TEST CLASS
WHEN DUPLICATION
Rule of 3

39. Code Kata: The GREETING KATA
/testdouble/contributing-tests/wiki/Greeting-Kata
/swkBerlin/kata-bootstraps

40. Retrospective
- “TDD as if you meant it”
- Design decisions
- Inputs&Outputs vs User Stories
- Test names (intention/behaviour, no implementation)
- Too much logic in tests
- Actual vs Expected

41. Actual vs Expected
assertThat(expected, is(actual))
assertThat(actual, is(expected))

42. A side benefit: coverage

45. Code Kata: BANK ACCOUNT KATA
/swkBerlin/kata-bootstraps
Given a client makes a deposit of 1000 on 10-01-2012
And a deposit of 2000 on 13-01-2012
And a withdrawal of 500 on 14-01-2012
When she prints her bank statement
Then she would see
date || credit || debit || balance
14/01/2012 || || 500.00 || 2500.00
13/01/2012 || 2000.00 || || 3000.00
10/01/2012 || 1000.00 || || 1000.00
NO COMPUTERS!!

46. CRC Cards

47. CRC Cards
http://c2.com/doc/oopsla89/paper.html
A Laboratory For Teaching
Object-Oriented Thinking
Kent Beck, Apple Computer, Inc.
Ward Cunningham, Wyatt Software Services, Inc.

48. Growing Object-Oriented Software, Guided by Tests
Steve Freeman and Nat Pryce

49. @Test
public void should_print_a_bank_statement_in_reversed_chronological_order() {
given(clock.now()).willReturn(LocalDate.of(2014, 4, 1));
accountService.deposit(1000);
given(clock.now()).willReturn(LocalDate.of(2014, 4, 2));
accountService.withdraw(100);
given(clock.now()).willReturn(LocalDate.of(2014, 4, 10));
accountService.deposit(500);
accountService.printStatement();
verify(console).print("DATE | AMOUNT | BALANCE");
verify(console).print("10/04/2014 | 500.00 | 1400.00");
verify(console).print("02/04/2014 | -100.00 | 900.00 ");
verify(console).print("01/04/2014 | 1000.00 | 1000.00");
}

50. Retrospective
- Design decisions
- Inputs&Outputs vs User Stories
- Test names (intention/behaviour, no implementation)
- Too much logic in tests
- Additional code for testing

51. Additional code for testing
- Equality Pollution
- JSON, XML, … readers
- Additional features

54. @codurance_ES
@ertorser
@bberrycarmen