Better Functional Design through TDD

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/

http://amzn.to/vZv4Yw

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?

http://amzn.to/vZv4Yw

“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

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 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

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 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

http://xkcd.com/552/

http://soundcloud.com/jobs

http://philcalcado.com	672
http://blog.fragmental.com.br	102
http://www.philcalcado.com	94
http://www.fragmental.com.br	61
http://fragmental.com.br	43
http://a0.twimg.com	4
http://us-w1.rockmelt.com	1
http://prox.moraphi.com	1

Better Functional Design through TDD

by Phil Calçado on Nov 02, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

8 Embeds 978

Statistics

Better Functional Design through TDD — Presentation Transcript