Test Driven Development Coding Katas

1. Test Driven Development Coding Katas Adrian O’Sullivan, lead application developer Deutsche Bank global Technology

2. What is • TDD

3. What is TDD

4. What is a • Kata

5. What is a Kata?

6. Karate Katas • Sand the floor • Right the circle • Left the circle • Breath in breath out Paint the fence Paint up Paint down Breath in out (no look me look fence!) • Wash the car • Wax on – right hand circle • Wax off – left hand circle • Breath in breathe out

7. What is a Coding Kata? As a group, software developers don’t practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well. Other creative professions practice: artists carry a sketchpad, musicians play technical pieces, poets constantly rewrite works. In karate, where the aim is to learn to spar or fight, most of a student’s time is spent learning and refining basic moves. The more formal of these exercises are called kata. Dave Thomas http://codekata.pragprog.com, 2007

8. TDD Katas • 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.

9. TDD Kata • Demo

10. Roman Numerals Kata Return a string with the Roman Numerals for a given integer. Remember to follow the rules of TDD. Wax on, wax off, breathe!

11. TDD Katas • Fibonacci Sequence • Print the sum of the previous two numbers • FizzBuzz • If divisible by 3, fizz • If divisible by 5, buzz • If divisible by both , fizzbuzz 1 2 fizz 4 buzz fizz 7 8 fizz buzz 11 fizz 13 14 fizzbuzz

12. TDD katas • Tennis scoring • Bowling scoring • String Calculator • PacMan • Pacman needs to move about on a grid. Given - something • When – something • Then - something

13. http://www.cyber-dojo.com

14. Why do this • One of the reasons TDD is hard for newcomers is that it is very explicit about the baby-step nature of the changes you make to the code. You simply are not allowed to add anything more than the current tests require. And for experienced developers, this is very hard to do, especially when working on real code.

15. Why do this • TDD is not taking • TDD cadence • System complexity • Try new libraries • Learn shortcuts • Learn from other developers • Understand a new language • Understand an old language • Its fun

16. Styles of Kata • Solo • Daily • Weekly • Group • Write a test, pass a test, pass the keyboard • Pass a test, write a test , pass the keyboard • 4 person group • n Pairs

17. Discussions • Whether to use one assert or multiple asserts in each test • When to use mocks and when its better to use stubs • Is it ok to change the access level of methods from private to protected or public? • TDD/OO vs functional programming • How complex problems broken into small chunks • It takes discipline to not make 'improvements' to the code for which there is not yet a failing test! Its so tempting to make untested changes, but doing so usually ends in an unhappy experience and gets rolled back. • The logic of implementing the 'simplest thing that could possibly work‘

18. Lessons Learnt • Mac/Windows keyboards are not the same! • Don’t rely on network access • Sit together • Pairs of people new to TDD need supervision • Do the kata yourself before supervising a group session • Expect inconsistent attendance