Real Developers Don't Need Unit Tests

Real Developers Don’t Need Unit Tests
Mythbusting TDD myths

John Ferguson Smart
Wakaleo Consulting Ltd.
http://www.wakaleo.com
Email: john.smart@wakaleo.com
Twitter: wakaleo

Introduction

Introduction
Bugs?

Introduction
Bugs?

Chuck Norris’s code doesn’t have bugs

Introduction
Bugs?

Chuck Norris’s code doesn’t have bugs

His code always work. ALWAYS.

Introduction
Bugs?
Emergent design?

Introduction
Bugs?
Emergent design?

Chuck Norris’s code is perfectly
designed the first time round

Introduction
Bugs?
Emergent design?

Chuck Norris’s code is perfectly
designed the first time round

His favorite design pattern is the
Roundhouse Kick

Introduction
Bugs?
Emergent design?
Technical documentation?

Introduction
Bugs?
Emergent design?

Chuck Norris doesn’t need
technical documentation

Introduction
Bugs?
Emergent design?

technical documentation

He just stares down the code until it
tells him everything he wants to know

Introduction
Bugs?
Emergent design?
Executable requirements?

Introduction
Bugs?
Emergent design?

requirements to be executable

Introduction
Bugs?
Emergent design?

requirements to be executable

He can execute whatever he wants

Introduction
Bugs?
Emergent design?
Acceptance Tests?

Introduction
Bugs?
Emergent design?
Acceptance Tests?

acceptance tests

Introduction
Bugs?
Emergent design?
Acceptance Tests?

acceptance tests

No one refuses to accept Chuck

Introduction

OK, so Chuck Norris doesn’t need Unit Tests

Introduction

OK, so Chuck Norris doesn’t need Unit Tests

But what about the rest of us?

TDD Basics

So what is this TDD thing, anyway?

TDD Basics
TDD is not about writing tests


TDD Basics
TDD is a design strategy:


TDD Basics
Write better-designed code


TDD Basics
Have more conﬁdence in our code


TDD Basics
Make changes more easily


TDD Basics
Write code that meets user requirements more accurately


TDD Basics
(and incidentally...)


TDD Basics
(and incidentally...)
Build up a comprehensive set of automated tests


TDD Basics
The TDD development process
“Never write a single line of code unless you have a failing automated test.
Eliminate duplication.”
- Kent Beck

TDD Basics
- Kent Beck

TEST Write a failing unit test. Ensure that it fails.

TDD Basics
- Kent Beck


CODE Write production code to make the test pass.

TDD Basics
- Kent Beck


CODE Write production code to make the test pass.

REFACTOR Tidy up the design

TDD Basics
TEST

CODE

REFACTOR

TDD Basics
Step 1) Write a test TEST

CODE

REFACTOR

TDD Basics

Design your code from the outside-in
CODE

REFACTOR

TDD Basics

How will your code be used? CODE

REFACTOR

TDD Basics


Design a clean interface for your code
REFACTOR

TDD Basics


Implement only features that are really needed REFACTOR

TDD Basics



Provide examples of how you expect your code
to be used

TDD Basics



Provide examples of how you expect your code
to be used
How will my code be used by the
rest of the application?

?

TDD Basics
Step 2) Write some code TEST

CODE

REFACTOR

TDD Basics

Just enough code to make the tests pass
CODE

REFACTOR

TDD Basics

Might mean a non-optimal solution at this stage... CODE

REFACTOR

TDD Basics

Might mean a non-optimal solution at this stage... CODE

REFACTOR

Just make it pass the test...

TDD Basics
TEST

CODE

REFACTOR

It works. Now let’s tidy things up.

TDD Basics
Step 3) Tidy up TEST

CODE

REFACTOR


TDD Basics

Evolutionary (emerging) design
CODE

REFACTOR


TDD Basics

Keep the code clean! CODE

REFACTOR


TDD Basics


Remove duplication and ﬁx design problems
REFACTOR


TDD Basics


Restructure existing code - no new features! REFACTOR


TDD Basics


Restructure existing code - no new features! REFACTOR

Make sure the tests still pass!


TDD in Action - the Game Of Life


So where do we start?



Let’s list some requirements



Let’s list some requirements

The Game of Life
- Live cells with less than 2 live neighbours die
- Live cells with more than 3 live neighbours die
- Live cells with 2 or 3 live neighbours remain alive
- Dead cells with 3 neighbours become alive

TDD in Action

The Game of Life
- Live User Story 1or Less than 2 neighbours die
cells with 2 - 3 live neighbours remain alive
- Dead cells cell with less than 2 live neighbours
Given a with 3 neighbours become alive
When the next generation is created
Then this cell will die

TDD in Action

Now what?

The Game of Life

TDD in Action

Now what?

So what do we mean by this first requirement?

The Game of Life

TDD in Action

So what do we have to code for this one.

The Game of Life

TDD in Action


Dunno yet. Let’s write some acceptance tests to find out

The Game of Life

TDD in Action


Dunno yet. Let’s write some acceptance tests to find out

The Game of Life
- Live UserUser StoryLessAcceptance criteria die
cells Story 1or 3 live neighbours remain alive
with 2 - 1 - than 2 neighbours
Sample grid transitions:
1) 2)

TDD in Action

Great, so now I can start coding, right?

TDD in Action


Not so fast, hot shot. We need to turn this into an
‘executable requirement’

TDD in Action


Not so fast, hot shot. We need to turn this into an
‘executable requirement’

public class GameOfLifeTest {

@Test
public void aCellWithNoNeighboursShouldDieInTheNextGeneration() {
}
}

TDD in Action


@Test
}
}

TDD in Action

I still don’t know what to write in this test...


@Test
}
}

TDD in Action


Start by expressing what you are trying to achieve


@Test
}
}

TDD in Action


Start by expressing what you are trying to achieve


@Test
String initialGrid = "...n" +
"...n" +
"...";

String expectedNextGrid = "...n" +
"...n" +
"...";

String nextGrid = null;
assertThat(nextGrid, is(expectedNextGrid));
}
}

TDD in Action


@Test
"...n" +
"...";

"...n" +
"...";

}
}

TDD in Action

But that test will fail! What now?


@Test
"...n" +
"...";

"...n" +
"...";

}
}

TDD in Action


How you would like the code to look, if you had to use it?


@Test
"...n" +
"...";

"...n" +
"...";

}
}

TDD in Action


How you would like the code to look, if you had to use it?


@Test
"...n" +
"...";

"...n" +
"...";

Universe theUniverse = new Universe(seededWith(initialGrid));
theUniverse.createNextGeneration();

String nextGrid = theUniverse.getGrid();
}
}

TDD in Action


@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action
So what’s so special about this test?


@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action
The test name describes
the expected behaviour

@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action

@Test
"...n" +
"...";

"...n" +
"...";


}
} We started by expressing our expectations

TDD in Action

@Test
"...n" +
"...";

String expectedNextGrid = "...n" + The code is written for API
"...n" +
users, not API developers
"...";


}

TDD in Action

@Test
"...n" +
"...";

It’s a working String expectedNextGrid = "...n" + The code is written for API
example of how "...n" +
users, not API developers
to use the class "...";


}

TDD in Action

So what now?


@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action

So what now?

This is our acceptance test. Now we drill down.


@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action

So I guess you’ll say we need to write a test?


@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action


Spot on! You catch on fast!


@Test
"...n" +
"...";

"...n" +
"...";


}
}

TDD in Action


Spot on! You catch on fast!

public class UniverseTest {

@Test
public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() {

@Test
String seededGrid = "...n" +
"...n" +
"...";
"...n" +
"...";
Universe theUniverse = new Universe(seededWith(seededGrid));
String currentGrid = theUniverse.getGrid();
assertThat(currentGrid, is(seededGrid));
"...n" +
}
"...";
}


}
}

TDD in Action


@Test

"...n" +
"...";

}
}

TDD in Action

So now can we code?


@Test

"...n" +
"...";

}
}

TDD in Action

So now can we code?

Yes, but just a little bit


@Test

"...n" +
"...";

}
}

TDD in Action

So now can we code?

Yes, but just a little bit


@Test public class Universe {
public Universe(String initialGridContents) {}
public static String seededWith(String gridContents) {
"...n" +
return null;
"...";
}
public void createNextGeneration() {}
} public String getGrid() {
} return "...n" +
"...n" +
"...";
}
}

TDD in Action

Er, isn’t that a bit too simple.

TDD in Action


Yes. We need another test to tease out
a more complete design

TDD in Action




@Test
public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() {...}

@Test
public void aUniverseSeededWithANonEmpyGridContentWillContainThatGrid() {

".*.n" +
"...";

}
}

TDD in Action



public class Universe {

public class UniverseTest { private String currentContent;

@Test public Universe(String initialGridContents) {
public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() {...}
currentContent = initialGridContents;
}
@Test
public void aUniverseSeededWithANonEmpyGridContentWillContainThatGrid() {
return gridContents;
}
".*.n" +
"...";
public void createNextGeneration() {
}
public String getGrid() {
return currentContent;
} }
} }

TDD in Action


private String currentContent;

public Universe(String initialGridContents) {
}

}

}

}
}

TDD in Action

Well, now at least those two
tests pass.



}

}

}

}
}

TDD in Action

Well, now at least those two
tests pass.

Now we need to implement the
‘createNextGeneration()’ method...



}

}

}

}
}

TDD for unbelievers

So TDD is the answer to all my problems?

No, sorry, TDD is not a Silver Bullet

You still have to use your brain
Also use other design activities (domain modeling, DDD,...)
TDD is not applicable everywhere
Highly visual coding, ‘know it when you see it’ stuff,...
TDD works best if you have a vision

TDD for unbelievers

But how can I write tests if I don’t know what the code looks like?

How can you write code when you can’t express what it
should do?

“Write code for others as you would have them write code for you”
- Some agile dude

TDD is about expressing the intent of your code
It is a design practice
Design your code “outside-in”

TDD for unbelievers

I don’t have time to write tests

But you have time to fix the code afterwards, right?

“I can get it done much faster if it doesn’t have to work”
- Kent Beck (paraphrased)

New TDDers will take maybe 20-30% longer
Experienced TDD developers don’t spend much (if any)
more time coding
But the code is of much higher quality

TDD for unbelievers

But I'm writing more test code than application code!

Sure, writing tests is part of the process

You will write lots of tests...
...but your code will be more focused and more accurate

TDD for unbelievers

My tests break whenever I change my code

Try to test the behaviour, not the implementation

Validate behaviour, don’t verify implementation

TDD for unbelievers

Our tests are too hard and take too much time to keep up to date

Treat your test code as production code

Be wary of test maintenance overhead
Test code is not second-class code
Refactor to keep your test code maintanable
Avoid technical dept

TDD for unbelievers

I found a bug in the production code. TDD doesn’t work.

see “TDD is not a Silver Bullet”

You still need your testers!
You can still make mistakes...
...but they are easier to isolate and to fix
If you find a bug, just add another test to reproduce it, then fix it!

TDD for unbelievers

I’ve heard TDD encourages sloppy design. Isn't it better to have a
general vision of the problem before coding the solution?"

Sometimes, yes. That's what the refactoring phase is for.

TDD does not preclude initial high-level design
Brainstorm a high-level design approach
Deﬁne a common well-known domain language
Use an ‘Iteration 0’ and spikes
Don’t be afraid to refactor
TDD works better when you have a vision

TDD for unbelievers

I use a database/network/web service... and TDD-style unit tests
can't test it. TDD doesn't work

You will need integration tests too

Unit tests when you can, integrations tests when you must
Integration tests for system boundaries
Mock out these boundary classes for the rest of your tests

TDD for unbelievers

Our BAs and product owners aren’t buying this TDD stuff

Try putting them into the feedback loop

Acceptance-Test Driven Development is about communication
BDD help BAs and POs participate in writing executable requirements
scenario "A cell with less than 2 live neighbours should die", {
given "Given a cell with no live neighbours",
when "a new generation is generated",
then "that cell will have died"
}

TDD for unbelievers



scenario "A cell with less than 2 live neighbours should die", {
given "Given a cell with no live neighbours", {
initialGrid = ""...
.*.
...""
theUniverse = new Universe(seededWith(initialGrid));
}
when "a new generation is generated", {
theUniverse.createNextGeneration()
}
then "that cell will have died", {
theUniverse.grid.shouldBe ""...
...
...""
}
}

TDD for unbelievers



Given a living cell with no live neighbours like this
...
.*.
...
When a new generation is generated
then the grid should look like this:
...
...
...

TDD for unbelievers

Many BDD tools also have great reporting features

Test results summary

Unimplemented stories

Failed stories

TDD for unbelievers

Many BDD tools have great reporting features

Test results summary

Test failure details

Unimplemented stories

TDD for unbelievers

“I’ve tried TDD, but I soon lapse back into my old code-first habits”

TDD takes practice and know-how

Unit tests when you can, integrations tests when you must
Learn about TDD - read books on TDD practices
Do pair program with someone who knows TDD
Participate in and organize coding dojos
<blatant plug>Training/mentoring</blatant plug>

Conclusion
Real Developers Don’t Need Unit Tests?

So maybe Chuck should be writing
unit tests after all...

I agree. You go talk to him

Thank You

John Ferguson Smart
Wakaleo Consulting Ltd.
http://www.wakaleo.com
Email: john.smart@wakaleo.com
Twitter: wakaleo

Real Developers Don't Need Unit Tests

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Real Developers Don't Need Unit Tests (20)

More from John Ferguson Smart Limited (20)

Recently uploaded (20)

Real Developers Don't Need Unit Tests