TDD Transformed

With new insights around Specification Driven Design I aim to help you get closer to that elusive state that artists express when sometimes the code seem to almost be writing itself.

Transcript

1. TDD Transformed Richie Khoo @evolve2k
2. Test
3. HOW MUCH TIME DO YOU ENJOY SPENDING DEBUGGING CODE?
4. Test Driven Design
5. Test Driven Design
6. Test Driven Design
7. Kent Becks 4 Rules of Simple Design 1. Runs all the tests 2. Expresses every idea we need to express 3. Says everything once and only once (no duplication) 4. Has no superfluous parts Simple Design
8. Specification Driven Design
9. Specification Driven Design •Describe Tram
10. Specification Driven Design •Describe Tram •it ‘has an engine’ •it ‘can be started’ •it ‘has many passengers’ •it ‘can stop to let passengers off’
11. RSpec
12. Red > Green > Refactor
13. Introducing Expected
14. Expected is a happy way point on the journey from red to green in the red/ green/refactor cycle of test driven development.
15. Red > Expected > Green > Refactor
16. You reach Expected when the way the test is failing, is as you would expect it to fail, based on the test logic. If the test is failing for some other reason, that is not expected per the test logic, then it is still red.
17. RSpec
18. Red > Expected > Green > Refactor
19. Uncle Bob’s 3 rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass 2. You are not allowed to write any more of a unit test than is sufficient to fail 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test
20. GOOD TDD IS ABOUT SMALL STEPS THAT GENERALLY TAKE LESS THAN A MINUTE
21. EXERCISE 1: TDD 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”
22. Transformations Refactoring's have counterparts called Transformations. Refactoring's are simple operations that change the structure of code without changing it’s behavior. Transformations are simple operations that change the behavior of code. Transformations can be used as the sole means for passing the currently failing test in the red/green/refactor cycle. —‘Uncle Bob’ Martin
23. ‘Transformations Priority’ Premise Transformations have a priority, or a preferred ordering, which if maintained, by the ordering of the tests, will prevent impasses, or long outages in the red/green/refactor cycle. —‘Uncle Bob’ Martin
24. Transformation Priority Transformation  Name Example 1 no  code  -­‐>  nil no  code  -­‐>  nil 2 nil  -­‐>  simple  constant nil  -­‐>  “”,  1 3 constant  -­‐>  constant+ “”,  1  -­‐>  “Australia”,  42 4 constant  -­‐>  variable “Australia”  -­‐>  country 5 statement  -­‐>  statements country  =  “Australia”    -­‐> country  =  “Australia”;  puts  “G’Day!” 6 unconditional  -­‐>   conditional no  if  -­‐>  if,  unless,  ternary  if  statement 7 variable  -­‐>  array dog  -­‐>  [dog,  cat] 8 array  -­‐>  collection [dog,  cat]  -­‐> {dog:  ‘woof’,  cat:  ‘meow’} 9 statement  -­‐>  recursion statement  -­‐>  recursion(recursion) 10 if  -­‐>  while/loop  if  door_open?  -­‐>  while(door_open?) 11 expression  -­‐>  method  call Date.today  -­‐  birthdate  -­‐>  age_in_days(birthdate) 12 variable  -­‐>  assignment days_left  -­‐> days_left  =  10 When coding prioritise the transformations at the top of the list over the more aggressive state transformations at the bottom.
25. Guard Clause Tip Corey Haines likes to use a Guard clause to help him reset his code to returning the nil state as a nice easy way to get back to the bottom of the Transformation Priority staircase.
26. A Guard Clause is just an explicit return statement at the top of a method. It is so called as it is said to guard the rest of the contents of the method.
27. I write a spec and get it passing..
28. When writing the next spec.. ..I get this awkward error
29. Add a Guard Clause around “Fizz” ..gives nice expected nil for TPP
30. EXERCISE 2: TDD DUCKYFUZZ Write a program that prints the numbers from 100 to 1. But for multiples of four print "Ducky" instead of the number and for the multiples of seven print "Fuzz". For numbers which are multiples of both four and seven print "FuzzyDucky” This time use the Transformation Priorities and the other rules to guide every design decision
31. Thank you. Happy Speccing! Transformation Priority Premise (Uncle Bob) http://en.wikipedia.org/wiki/Transformation_Priority_Premise Corey Haines Roman Numerals Kata http://programmingtour.blogspot.com.au/2012/12/roman-numerals-kata- with-commentary.html Extending Red, Green, Refactor with Expected http://richiekhoo.com/post/49820134249/extending-red-green-refactor-with- expected