TDD In Practice

What, why, and how.

What is TDD?

Wait a second… is this a trick question?

What is TDD?

Not just test-first

● test-first is a is a statement about workflow

● test-first says nothing about design

● test-first says nothing about improving existing (legacy) code

● test-first is not a bad thing

Write Tests

Write Code

Run Tests

Test-first development

What is TDD?

Philosophy of workflow and design

1. Red 2. Green3. Refactor

● System design expressed and refined through tests

● Simplest possible code written to make test pass

● Repeat cycle for every test

RED(fail)

GREEN (pass)

REFACTOR (improve)

What is TDD?

NOT “bumpers” to bang your code against until it works

What is TDD?

Safety net to accompany thoughtful coding.1

Why TDD?

Clarify expectations

Ask yourself:

● What is this feature supposedto do?

● What are the components?

Validate the state of the system

Assertions about functionality:

“When I do this, I should get that.”

Especially important in dynamic languages where the compiler cannot enforce type correctness

Assertions about relationships:

“A should call B with (X, Y)”

Relationships are tricky… mock if you want.

Break big problems into several smaller problems

TDD forces you to consider a number of issues at the offset:● Dependencies● Complexity● Alternate implementations● Dead code

Protect against regressions

There’s no way that this could cause anything to break...

*code**code**code*

Don’t make Uncle Bob mad

How to do TDD

Write single small test

Epic fail = ¡Bueno!

<Controversy>Those weak in stomach may at this point

look away.

Write just enough code to make it pass.

Write just enough code to make it pass.^intelligen

t

</Controversy>As you were.

Think about other inputs & edge cases

Think about other inputs & edge cases

It’s complicated…Testing relationships with mocks

What happens when you need to talk to an external resource?

What happens when you need to talk to an external resource?

You use a mock to “stand in” for it

1. Create Mock2. Set Expectations3. Execute client code

1

2

3

(PHPUnit has lots of tools for mocking)2

$this->any() May be called any number of times

$this->once() May be called only 1x

$this->at($n) Expect something the nth time called

$this->returnValue() Pretend it returned a specific value

$this->greaterThan($n) May be called with any value > n

… so much more!

What happens when you need to talk to an external resource?

Then, you write the code to make it pass.

● Do we consider this code “untestable”?● Do we sign up for a Twitter account just for our

automated tests? (rate limiting? long test runs?)● Do we take the time to go back and refactor to improve

the design?

What might this have looked like w/o TDD?

Implicit Dependency

Makes actual API call

1. Guard rail analogy borrowed from “Simple Made Easy”

by Rick Hickey

http://www.infoq.com/presentations/Simple-Made-Easy 2. PHPUnit Documentation

http://phpunit.de/documentation.html

Sources