Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

The Road to Test Driven Development

This is a quick story about adopting TDD in a sizable project.
by

Steve McDuff

on 9 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Road to Test Driven Development

The Road to
Test Driven Development
I wanted to make an
open source project
to explore some of my ideas
Swing UI
Dynamic Compilation
GWT UI
Fast Application Development
But I was alone
TODO:
Design
Code
Test
Document
Everything
In the beginning,
all was well
Testing everything takes
only a few minutes
And the years passed,
and features accumulated
I'm so smart,
I know and remember all my code !
And Accumulated
And Accumulated
Which Lead to a small problem
Things kept on
BREAKING !!!
I wish I had a tester
to delegate all this testing...
There were a few problems:

Remembering all my code wasn't an option anymore

I found bugs that I had introduced 5 features ago.

A manual regression took an hour to run (boring)
Man, if I released
this software now,
I'd look like an idiot...
A possible Solution
I read about this TDD concept...

But I never got to really try it...
Why don't I just give it a real try
?
TDD = Test
Driven Development
Have a computer run all the boring stuff
Write test code ?
Why not, I like to write code.
I sat down and started
writing tests for
all my classes
A whole month without
adding new features,

yawn..
Initial Results

Found plenty of defects just waiting to be uncovered.

I could make changes deep in the framework and know exactly what would break within 30 seconds.
I can't believe the number of defects I found,
even in very simple code.

and I thought I was smart
:(
:)
An experience report on what TDD did
for my open source project
http://deduced.org
And then I introduced code coverage
Found Even More bugs

Found plenty of dead code and half completed classes
No way I'm going to spend time
writing tests for dead code
and useless classes.

Go Go Gadget Trash Bin
99.9% Coverage!
I should be able to ship this code now just by looking at those results
right ?
WRONG !
The first functional test I ran manually failed.
:(
:)
Oops, this test fixture
hid a defect.

Oh well, I'll add a quick TDD
tests to reproduce it and
we'll never see this defect again.

ADIOS
Even branch coverage
uncovered defects.
A few hundred tests later
Then, almost everything worked as expected.
Let's ship this release !
A few interesting facts:

For new code, if I got lazy and tried to do manual tests first, it would take as long to fix the code as it would take to write all my TDD tests.

But retesting a change manually took much more time

And my coverage was very low
A developer trying to be lazy ? That's got to be the first time it happens.
What if I have a big team?
We have people dedicated
for testing, so why bother.
by Steve McDuff
Why should this experience change, whether you are
One
or
One Hundred
Time not spent testing is time spent doing something more useful
- Captain Obvious
Insert shameless plug here
Model Driven
Unavoidable facts of life:
Taxes
Death
Software Developer's over optimism
Full transcript