1.
Better Functional Design
through TDD
Phil Calçado – SoundCloud
@pcalcado
http://philcalcado.com

2.
This talk is not about how.

3.
Clojure TDD demo by Brian Marick
http://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 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.
http://amzn.to/vZv4Yw

8.
What Is the Point of
Test-Driven Development?

9.
1.Software development
is a learning process

10.
2.Feedback is the
Fundamental tool

11.
3.Practices that support
change

12.
But that is Development.
What about Design?

13.
http://amzn.to/vZv4Yw

14.
“There are three aspects of TDD
that help us achieve [good
design]:

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.
“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.
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 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.
On the (over-)usage of maps
http://bit.ly/sNSVz9

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.
“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 general
enough
Peter Norvig, Good Lisp Programming Style - http://bit.ly/u6JTPt

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.
“Determine dependencies.
Re-modularise to reduce
dependencies. 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 design
and 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