Better Functional Design through TDD

Uploaded on


More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Better Functional Design through TDDPhil Calçado – SoundCloud @pcalcado
  • 2. This talk is not about how.
  • 3. Clojure TDD demo by Brian Marick
  • 4. This talk is not about how. It is about why.
  • 5. The London School
  • 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
  • 7.
  • 8. What Is the Point ofTest-Driven Development?
  • 9. 1.Software developmentis a learning process
  • 10. 2.Feedback is theFundamental tool
  • 11. 3.Practices that supportchange
  • 12. But that is Development. What about Design?
  • 13.
  • 14. “There are three aspects of TDDthat help us achieve [gooddesign]:
  • 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. “Write code in terms of theproblems data types, not the types that happen to be in the implementation.” Peter Norvig, Good Lisp Programming Style -
  • 17. Reverse engineering.
  • 18. Lots of how. Not so much what or why.
  • 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 -
  • 20. On the (over-)usage of maps
  • 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. “Break the problem into parts. Design useful subparts. Be opportunistic.” Peter Norvig, Good Lisp Programming Style -
  • 23. Reverse engineering.
  • 24. Way too much stuff going on.
  • 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 -
  • 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. “Determine dependencies. Re-modularise to reducedependencies. Design most dependent parts first.” Peter Norvig, Good Lisp Programming Style -
  • 28. Introduce similar feature.
  • 29. Make it green.
  • 30. Make it better.
  • 31. Evolving to closures and combinators:
  • 32. I see strong correlation between good designand test-driven development.
  • 33. Code which is coupled and complicated is bad design
  • 34. Code which is coupled and complicated is hard to maintain
  • 35. Code which is coupled and complicated is hard to test
  • 36.
  • 37.