Test-driven development is generally regarded as a good move: it should result in simple decoupled design, your tests tend to cover behaviour not methods, and far fewer bugs. However, just getting unit tests in on a real, commercial project is hard - switching to TDD is even harder. Often you can start a project with good intentions and coverage, then the deadline looms and the tests go out then the hacks come in. So, instead of beating ourselves up about not being perfect let's look at an interative approach to adopting TDD principles. We'll look at tactics for selling TDD to your client, boss and colleagues. This talk will also cover methods for making TDD easier for you by showing you what tools you can use to integrate it into your development environment. In the project itself, we'll examine how we can make small but permanent steps towards full TDD, without losing that progress when deadlines hit. We'll also cover a few methods for learning on your own time and how the whole process can actually be made quite enjoyable.
6. THE GOOD
@
Clean code, smart devs
Latest technology
Building your career
Elitist / Intimidating?
DIFFERENT SITUATIONS
7. THE BAD
g
Disgusting code
Devs don't care
Career dead-end
Changes break the app.
Always bug-fixing
DIFFERENT SITUATIONS
8. THE UGLY
c
Good tests are hard
Writing tests takes time
Time is money
You're not an expert
(yet...)
DIFFERENT SITUATIONS
9. WHAT IS TDD?
1.Decide what you want to do
2.Write a test to show it working
3.Run the test and watch it fail
4.Write just enough code to pass the test
5.Re-run the test (and test suite)
6.Refactor (refine/improve)
7.Re-run tests
8.Repeat
11. WHY IS THIS HARD?
l
Do you know what
you want
before
you code it?
12. WHY IS THIS HARD?
l Does your client
know what
they want?
Ever?
13. Train yourself to think like a scientist
1.Hypothesis
2.Repeatable Experiment
3.Conclusions
]
14. ninja
Train yourself to think like a scientist
]
Kata
1.Hypothesis terally: "form")
( 型 or 形 , li
2.Repeatable movements
A set of Experiment
3.Conclusionsain and again
you repeat ag
ctly.
un til can do it perfe
Ninja weapon
15. !
DAVE THOMAS
co-author of
The Pragmatic
Programmer
Code Kata
http://code
kata.pragpro
g.co m/
16. ROY OSHEROVE - TDD Kata
http://osherove.com/tdd-kata-1/
Create a simple String calculator
with a method int Add(string numbers)
The method can take 0, 1 or 2 numbers,
and will return their sum
(for an empty string it will return 0)
for example “” or “1” or “1,2”
18. Now you're an expert...
warning
Do not assume you can
just start to do this
in your project D
19. DON'T BE A HERO
Introduce tests all at once...
●
You will miss your deadline
●
Your tests will not be maintained
●
Your team will hate you
20. DIFFERENT APPROACHES
Force tests
on your client
Make your client
want the tests L
21. FORCING TESTS
to your estimates.
Do not compromise
your principles.
L
Add a fixed percentage
22. SELLING TESTS
in creating tests.
Make the tests
a deliverable.
L
Use tests to define 'done'.
Involve the client
23. SELLING TESTS
Involve the client
in creating tests.
Make the tests
a deliverable.
L
Use tests to define 'done'.
Fitnesse Framework
http://fitnesse.org/
24. SELLING TESTS
Involve the client
in creating tests.
Make the tests
a deliverable.
L
Use tests to define 'done'.
Fitnesse Framework
http://fitnesse.org/
Selenium
http://seleniumhq.org/
25. DON'T BELIEVE THE HYPE
Make sure you don't over-promise.
Make sure you have the
infrastructure and skills
NO SILVER BULLETS
27. Unit/Acceptanc
provides the tec
1.Unit Testing
v
INFRASTRUCTURE
e testing
hnical base
2.Acceptance Testing
3.Automated Deployment
4.Continuous Integration
5.Issue Tracking
28. Unit/
Au s v
INFRASTRUCTURE
e testing
Acceptanc eployment
ate t d
tomthe d echnical base
provide a quick test env.
1.Unitows
all Testing
2.Acceptance Testing
3.Automated Deployment
4.Continuous Integration
5.Issue Tracking
29. Unit/
Au s ate t dv
INFRASTRUCTURE
e testing
Acceptanc eployment
tomthe d echnical rbasen
provide ntinuouckIte
Co s a qui
1.Unitow
makes pr
s eg atio
ntst env.
all Testing ogress visible
2.Acceptance Testing
3.Automated Deployment
4.Continuous Integration
5.Issue Tracking
30. INFRASTRUCTURE
Unit/
Au s ate t d
Co s a qui
s v
e testing
Acceptanc eployment
tomthe d echnical rbasen
provide ntinuouckIte
eg atio
ntst env.
ingviallows
1.UnitowIssue Traress sible
all Testing og ck
makes pr
2.Acceptance rting on TDD
repo Testing
3.Automated Deployment
4.Continuous Integration
5.Issue Tracking
32. REPORTING
c
Only trac k a metri
1.Code Coverage is useful
if it
2.Branch Coverage urages th
e
and enco
3.Bug Origin: behaviour
!
right
- tested code
- untested code
4.Test/Dev Time:
- per feature
- per story
33. SKILLS & THE TEAM
Owners not heroes
Prepared to fail
Honest & Disciplined