Better Functional Design through TDD

7,039 views

Published on

Published in: Technology, Education

Better Functional Design through TDD

  1. 1. Better Functional Design through TDDPhil Calçado – SoundCloud @pcalcado http://philcalcado.com
  2. 2. This talk is not about how.
  3. 3. Clojure TDD demo by Brian Marickhttp://bit.ly/sjCJBm http://www.flickr.com/photos/doug88888/4507077583/
  4. 4. This talk is not about how. It is about why.
  5. 5. The London School http://www.flickr.com/photos/doug88888/4507077583/
  6. 6. The London School1.Write a failing functional test2.Mark it as Work-in-progress3.Write a failing unit or integration test4.Make it pass5.Refactor6.Repeat steps 3 to 5 until your functionaltest passes http://www.flickr.com/photos/doug88888/4507077583/
  7. 7. http://amzn.to/vZv4Yw
  8. 8. What Is the Point ofTest-Driven Development?
  9. 9. 1.Software developmentis a learning process
  10. 10. 2.Feedback is theFundamental tool
  11. 11. 3.Practices that supportchange
  12. 12. But that is Development. What about Design?
  13. 13. http://amzn.to/vZv4Yw
  14. 14. “There are three aspects of TDDthat help us achieve [gooddesign]:
  15. 15. First, starting with a test meansthat we have to describe what wewant to achieve before weconsider how. This focus helpsus maintain the right levelof abstraction.
  16. 16. “Write code in terms of theproblems data types, not the types that happen to be in the implementation.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
  17. 17. Reverse engineering.
  18. 18. Lots of how. Not so much what or why.
  19. 19. To ensure that you say what you mean:1.Start with an English description of thealgorithm2.Write the code from the description3.Translate the code back to English4.Compare 3 to 1 Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
  20. 20. On the (over-)usage of maps http://bit.ly/sNSVz9
  21. 21. Second, to keep testsunderstandable and maintainable,we limit their scope. Tests thatare dozens of lines long tell usthat the component they’re testingis too large and needs breaking upinto smaller components.
  22. 22. “Break the problem into parts. Design useful subparts. Be opportunistic.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
  23. 23. Reverse engineering.
  24. 24. Way too much stuff going on.
  25. 25. Every function should have:●A single specific purpose●If possible, a generally useful purpose●A meaningful name●A structure that is simple to understand●An interface that is simple yet generalenough Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
  26. 26. Third, to prepare a component fora unit test, we have to pass itsdependencies to it, which meansthat we have to know what theyare. A component withimplicit (or just too many)dependencies is painful totest.”
  27. 27. “Determine dependencies. Re-modularise to reducedependencies. Design most dependent parts first.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
  28. 28. Introduce similar feature.
  29. 29. Make it green.
  30. 30. Make it better.
  31. 31. Evolving to closures and combinators:http://bit.ly/sTF5Nl
  32. 32. I see strong correlation between good designand test-driven development.
  33. 33. Code which is coupled and complicated is bad design
  34. 34. Code which is coupled and complicated is hard to maintain
  35. 35. Code which is coupled and complicated is hard to test
  36. 36. http://xkcd.com/552/
  37. 37. http://soundcloud.com/jobs

×