better functional design through tdd

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

On the (over-)usage of maps

http://bit.ly/sNSVz9

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

http://xkcd.com/552/

http://soundcloud.com/jobs