Better Functional Design through TDD

  • 4,992 views
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

Views

Total Views
4,992
On Slideshare
0
From Embeds
0
Number of Embeds
13

Actions

Shares
Downloads
34
Comments
0
Likes
9

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Better Functional Design through TDDPhil Calçado – SoundCloud @pcalcado http://philcalcado.com
  • 2. This talk is not about how.
  • 3. Clojure TDD demo by Brian Marickhttp://bit.ly/sjCJBm http://www.flickr.com/photos/doug88888/4507077583/
  • 4. This talk is not about how. It is about why.
  • 5. The London School http://www.flickr.com/photos/doug88888/4507077583/
  • 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. http://amzn.to/vZv4Yw
  • 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. http://amzn.to/vZv4Yw
  • 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 - http://bit.ly/u6JTPt
  • 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 - http://bit.ly/u6JTPt
  • 20. On the (over-)usage of maps http://bit.ly/sNSVz9
  • 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 - http://bit.ly/u6JTPt
  • 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 - http://bit.ly/u6JTPt
  • 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 - http://bit.ly/u6JTPt
  • 28. Introduce similar feature.
  • 29. Make it green.
  • 30. Make it better.
  • 31. Evolving to closures and combinators:http://bit.ly/sTF5Nl
  • 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. http://xkcd.com/552/
  • 37. http://soundcloud.com/jobs