better functional design through tdd
TRANSCRIPT
Better Functional Design through TDD
Phil Calçado – SoundCloud@pcalcado
http://philcalcado.com
This talk is not about how.
http://www.flickr.com/photos/doug88888/4507077583/
Clojure TDD demo by Brian Marickhttp://bit.ly/sjCJBm
This talk is not about how.
It is about why.
The LondonSchool
http://www.flickr.com/photos/doug88888/4507077583/
1.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 functional test passes
http://www.flickr.com/photos/doug88888/4507077583/
The London School
http://amzn.to/vZv4Yw
What Is the Point of Test-Driven Development?
1.Software development is a learning process
2.Feedback is the Fundamental tool
3.Practices that supportchange
But that is Development.What about Design?
http://amzn.to/vZv4Yw
“There are three aspects of TDD that help us achieve [good design]:
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.
“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
Reverse engineering.
Lots of how. Not so much what or why.
To ensure that you say what you mean:1.Start with an English description of the algorithm2.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
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.
“Break the problem into parts. Design useful subparts. Be
opportunistic.”
Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
Reverse engineering.
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 general enough
Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt
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.”
“Determine dependencies. Re-modularise to reduce
dependencies. 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 closuresand combinators:
http://bit.ly/sTF5Nl
I see strong correlation between good design
and 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 ishard to test
