The document describes a Global Day of CodeRetreat event taking place in Munich on November 18, 2017. The event involves 2000 developers from 100 cities and 6 continents pairing up to work through 6 sessions of test-driven development (TDD) exercises over 1 day using 1 kata (problem). Each session involves switching pairing partners and introduces constraints to challenge participants, such as writing tests first, continuous integration/refactoring, object-oriented principles, and functional programming techniques. The goal is for developers to learn and improve their TDD and software design skills in a low-pressure environment away from their day jobs.
27. KATA
TIC TAC TOE
3x3 Board
Player "X" and "O"
Player with 3 in one line wins
• horizontal
• vertical
• diagonal
28. SESSION 1 PART 1
"THE TEST LIST"
Goal
Understand
• the problem
• its test cases
29. SESSION 1 PART 1
"THE TEST LIST"
Collect a list of tests in a text file
(no coding yet!)
30. SESSION 1 PART 1
"THE TEST LIST"
Collect a list of tests in a text file
Player with 3 in one line wins
• horizontal
• vertical
• diagonal
31. SESSION 1 PART 1
"THE TEST LIST"
Sync
What tests do you have? Names?
Test categories? Dimensions?
Combinatorics?
32. SESSION 1 PART 2
"TEST FIRST"
Write a test and let it fail
Write the simplest possible
implementation that the test runs green
33. SESSION 1 PART 2
"TEST FIRST"
Why?
Set a clear goal
no YAGNI
Separate API from Implementation
Causality: Red->Green
Testing discipline, high coverage
early ROI
34. SESSION 1 PART 2
"TEST FIRST"
Write several tests and let them fail
35. SESSION 1 PART 2
"TEST FIRST"
Sync
Which tests did you write? Naming?
Object under Test?
Representation of Fields?
39. SESSION 2
"TDD + PING PONG"
Focus
write test: what should code do
implement: solve the problem
refactor: good design
40. SESSION 2
"TDD + PING PONG"
Uncle Bob’s 3 Rules of TDD
1. You can't write any production code until you
have first written a failing unit test.
2. You can't write more of a unit test than is
sufficient to fail, and not compiling is failing.
3. You can't write more production code than is
sufficient to pass the currently failing unit test.
42. SESSION 2
"TDD + PING PONG"
Ping Pong Pairing
1. Alice writes failing test
2. Bob makes test green
3. Bob writes failing test
4. Alice makes test green
5. Alice writes failing test
6. …
43. SESSION 2
"TDD + PING PONG"
Uncle Bob’s 3 Rules of TDD
1. You can't write any production code until you
have first written a failing unit test.
2. You can't write more of a unit test than is
sufficient to fail, and not compiling is failing.
3. You can't write more production code than is
sufficient to pass the currently failing unit test.
Do refactor duplication and improve names
44. SESSION 2
"TDD + PING PONG"
Sync
What did you observe?
What did (not) work?
What about design/refactoring?
How did pairing work?
45. SESSION 3
"BABY STEPS TDD"
LEARNING GOALS
Why are baby steps important
How to achieve baby steps
46. SESSION 3
"BABY STEPS TDD"
change 1
Initial code state
change 2
state 1
state 2
…
change n
target code state
● slow feedback
● high risk
● exponential complexity
● problems hard to find
LEAP
47. SESSION 3
"BABY STEPS TDD"
get green asap
● commit on green
● revert to green
change 1
Initial state
change 2
state 1
state 2
…
change n
target state
BABY STEPS
48. SESSION 3
"BABY STEPS TDD"
+ fast feedback
+ less risk
- a bit more effort
change 1
Initial state
change 2
state 1
state 2
…
change n
target state
BABY STEPS
49. SESSION 3
"BABY STEPS TDD"
Start a 2 min. timer when you get red
When back to green reset the timer and
When timer rings and you are still in red
git reset --hard
git commit
50. SESSION 3
"BABY STEPS TDD"
Sync
Did you get better during the session?
How did it work, was it hard?
How did you achieve baby steps?
59. SESSION 5
"OOP"
Constraints
Wrap all primitives and strings
Use first-class collections
Use only one dot per line
Keep all entities small
No more than two instance variables
Don’t use any getters / setters / properties
60. SESSION 5
"OOP"
Why?
Wrap all primitives and strings
Use first-class collections
Use only one dot per line
Keep all entities small
No more than two instance variables
Don’t use any getters / setters / properties
61. SESSION 5
"OOP"
Constraints
Wrap all primitives and strings
Use first-class collections
Use only one dot per line
Keep all entities small
No more than two instance variables
Don’t use any getters / setters / properties
62. SESSION 5
"OOP"
Sync
• What was hard?
• How did you handle it?
• Which constraints make sense
for "real life"