Send the link below via email or IMCopy
Present to your audienceStart 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
Transcript of TDD
Interactive session about
Test Driven Development
Put your hand in the air
Seriously, put your
hand in the air
defects are dumb
Numeric Overflow = +-1000 M USD
Imperial Vs Metric = 653 M USD
forward or backward?
Writing tests AND writing codes takes more time than just writing code
TDD will not validate our system
This TDD business is only for small bugs - we don't have such bugs here.
TDD Slow ?
"1 line of test code for every 1 line of code means that a TDD'er
writes twice as much code for the same amount of functionality
Seperation of concerns
Total code implementation time
is typically shorter
Code is easier to maintain and extend
(unless you're creating an API used
by some other developers)
Rather than writing documentation, make the code more readable!
Typing is not the problem....
Developer statistics - what takes up most of your time?
Running the debugger to see what was suppossed to happen, but didn't...
Setting up things just right so that that the debug session repeats the bug in production...
Sitting with someone else to show them in the debugger why their code doesn't work...
Reading log files
Typing is not the problem....
It all boils down to...
A software defect is the result from an object not doing what it is expected to do.
Testing each object to the extent of it's responsabilities, helps reduce these effects.
TDD is not for large scale projects
All large solutions don't just materialize out of nowhere;
they are ultimately created in modest steps anyway
(think in small units)
TDD has a serious track record.
Nasa is experimenting with TDD since 1960
“ Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
“ Programming is like sex: one mistake and you’re providing support for a lifetime.
I like to change and refactor code without having fear!
TDD != no bugs or no software defects
A bug = a missing test or
a wrong test
101 to fix bug:
write a test that reproduces it and thus fails
fix the test
You stop writing code that won't be used!
You have example code that shows what your code does!
The 3 laws of TDD
You are not allowed to write any production code unless it is to make a failing unit test pass
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Whitebox.set(account, "accountService", accountService);
account.getBallance() => Whoohoo
Think about what tests you're writing.
Don't write empty tests.
TAKE YOUR TIME
Write a very small amount of code.
This should break your build.
Write only enough code to fix the test.
Don't worry about it being pretty.
Refactor your code without fear.
Improve the look, remove smells.
After each change, run your test and make sure it still passes.
Do the whole cycle again.
You should be repeating this cycle many times an hour.
(20 - 40)
What defines good tests?
Fast: tests should run fast!
Independent: they should not depend on each other
Repeatable: they should be repeatable in any environment
Timely: write test before production code
but above all
Who likes to play bowling?
Let's create a bowling score app!
each frame is 2 rolls
= 10 pins in 2 tries
score = 10 + pins from next roll
= 10 pins in 1 try
score = 10 + pins from next 2 rolls
10th frame and strike or spare?
extra rolls to complete frame
Less Legacy code
Legacy code = code without tests