6. Dojo Rules
We respect each
other’s commitment
(No phones, email,
Facebook etc)
We all do TDD
We all do pair
programming
We do “Simple
Design”
7. Simple Design
All tests pass
Clear, expressive and
consistent
Does not duplicate
behaviour or
configuration
Minimises the number
of classes and methods
8. Format
Pair up
A problem is presented to be solved
We work on it in pomodoros (25 minute
cycles) - http://tomato.ist/gcd
When time up, 5 minute break to demo
your code to nearby pair, and reflect
At the end we show & tell our code
9. TDD Refresh
Write a failing test
Watch it fail(!)
Write code to make it pass
Refactor
Rinse & repeat
10. Uncle Bob’s Laws of TDD
You may not write production code until
you have written a failing unit test
You may not write more of a unit test
than is sufficient to fail (not compiling
is a counted as a test failure)
You may not write more production code
than is sufficient to pass the currently
failing test
11. FizzBuzz
Write a program that
prints the numbers from 1
to 100. But for multiples
of three print “Fizz”
instead of the number and
for the multiples of five
print “Buzz”. For numbers
which are multiples of
both three and five print
“FizzBuzz”:
1, 2, Fizz, 4, Buzz,
Fizz, 7, 8, Fizz, Buzz,
11, Fizz, 13, 14,
FizzBuzz, 16, 17, etc...
17. FizzBuzz (3)
Now modify your code to
print “Fizz” for
multiples of 3 AND
numbers with digit 3 in
them!
Multiple of 3 or contains
digit ‘3’: Fizz
Multiple of 5: Buzz
Multiple of 7: Whizz