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

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

TDD

An intro to TDD (Test Driven Development). Based on Prezi's from Rohan Kuruvilla and Craig Norton
by

Ronald Dehuysser

on 14 June 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of TDD

TDD
Interactive session about
Test Driven Development
Put your hand in the air
Seriously, put your
hand in the air
Why
How
Concerns
Most software
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
"
GUESS WHAT?
Cleaner code
Seperation of concerns
Benefits
Less debugging
Easier debugging
Total code implementation time
is typically shorter
Code is easier to maintain and extend
Documentation
is evil!
(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...
63%
Setting up things just right so that that the debug session repeats the bug in production...
20%
Sitting with someone else to show them in the debugger why their code doesn't work...
7%
Reading log files
10%
Typing is not the problem....
Reading is!
63%
20%
7%
10%
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
For me?
“ Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
(Martin Golding)
“ Programming is like sex: one mistake and you’re providing support for a lifetime.
(Michael Sinz)
I like to change and refactor code without having fear!
(Ronald)
WHAT
Unit test
Integration test
Acceptance test
TDD != no bugs or no software defects
A bug = a missing test or
a wrong test
101 to fix bug:
reproduce it
frame it
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
(uncle Bob)
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.
Tools
Maven dependencies
AssertJ
Mockito
assertThat(yoda).isInstanceOf(Jedi.class)
.isEqualTo(foundJedi)
.isNotEqualTo(foundSith);
when(accountService.getBallance()).thenThrow(new TooMuchMoneyException());
@Runwith(MockitoJUnitRunner.class)
Whitebox.set(account, "accountService", accountService);
account.getBallance() => Whoohoo
Google Guava
Lists.newArrayList(yoda, luke);
Productivity
Eclipse shortcuts
CLCL
Selenium IDE
Routine
THINK
RED
GREEN
REFACTOR
REPEAT
THINK
Think about what tests you're writing.
Don't write empty tests.
TAKE YOUR TIME
RED
Write a very small amount of code.
This should break your build.
(1 minute)
GREEN
Write only enough code to fix the test.
Don't worry about it being pretty.
(30 seconds)
REFACTOR
Refactor your code without fear.
Improve the look, remove smells.
After each change, run your test and make sure it still passes.
REPEAT
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
Self-validating:
RED
or
GREEN
Timely: write test before production code
but above all
READABLE
Demo Time
Who likes to play bowling?
Let's create a bowling score app!
10 frames
each frame is 2 rolls
Spare
= 10 pins in 2 tries
score = 10 + pins from next roll
Strike
= 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
Full transcript