Better Functional Design through TDDPresentation Transcript
Better Functional Design through TDDPhil Calçado – SoundCloud @pcalcado http://philcalcado.com
This talk is not about how.
Clojure TDD demo by Brian Marickhttp://bit.ly/sjCJBm http://www.flickr.com/photos/doug88888/4507077583/
This talk is not about how. It is about why.
The London School http://www.flickr.com/photos/doug88888/4507077583/
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/
What Is the Point ofTest-Driven Development?
1.Software developmentis a learning process
2.Feedback is theFundamental tool
3.Practices that supportchange
But that is Development. What about Design?
“There are three aspects of TDDthat help us achieve [gooddesign]:
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.
“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
Lots of how. Not so much what or why.
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
On the (over-)usage of maps http://bit.ly/sNSVz9
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.
“Break the problem into parts. Design useful subparts. Be opportunistic.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
Way too much stuff going on.
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
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.”
“Determine dependencies. Re-modularise to reducedependencies. Design most dependent parts first.” Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
Introduce similar feature.
Make it green.
Make it better.
Evolving to closures and combinators:http://bit.ly/sTF5Nl
I see strong correlation between good designand test-driven development.
Code which is coupled and complicated is bad design
Code which is coupled and complicated is hard to maintain
Code which is coupled and complicated is hard to test