Successfully reported this slideshow.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Better Functional Design through TDD

  1. 1. Better Functional Design through TDD Phil Calçado – SoundCloud @pcalcado http://philcalcado.com
  2. 2. This talk is not about how.
  3. 3. Clojure TDD demo by Brian Marick http://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 School 1.Write a failing functional test 2.Mark it as Work-in-progress 3.Write a failing unit or integration test 4.Make it pass 5.Refactor 6.Repeat steps 3 to 5 until your functional test passes http://www.flickr.com/photos/doug88888/4507077583/
  7. 7. http://amzn.to/vZv4Yw
  8. 8. What Is the Point of Test-Driven Development?
  9. 9. 1.Software development is a learning process
  10. 10. 2.Feedback is the Fundamental tool
  11. 11. 3.Practices that support change
  12. 12. But that is Development. What about Design?
  13. 13. http://amzn.to/vZv4Yw
  14. 14. “There are three aspects of TDD that help us achieve [good design]:
  15. 15. First, starting with a test means that we have to describe what we want to achieve before we consider how. This focus helps us maintain the right level of abstraction.
  16. 16. “Write code in terms of the problem's 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 the algorithm 2.Write the code from the description 3.Translate the code back to English 4.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 tests understandable and maintainable, we limit their scope. Tests that are dozens of lines long tell us that the component they’re testing is too large and needs breaking up into 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 general enough Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
  26. 26. Third, to prepare a component for a unit test, we have to pass its dependencies to it, which means that we have to know what they are. A component with implicit (or just too many) dependencies is painful to test.”
  27. 27. “Determine dependencies. Re-modularise to reduce dependencies. 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 design and 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

×