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.

1. Test Driven
u Development
andaid!
f
Gettin gP
Rowan Merewood
Software Eng. / Team Lead
Ibuildings

2. WHO AM I?
Software Engineer &
Technical Team Lead
at Ibuildings UK
I want to write good code
and earn a living
@rowan_m
m

3. Not ?
WHO AM I?
s
i-am-not-a
Cconsultant
well-maybe-a-little

4. Not ?
WHO AM I?
s
i-am-not
selling-a
book

5. Not ?
WHO AM I?
s
i-am-not
a-slave-to
one=method

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

10. WHAT IS TDD?
simplify
RED
H GREEN
REFACTOR

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”

17. .
ROY OSHEROVE - TDD Kata
demo

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

26. v
INFRASTRUCTURE
1.Unit Testing
2.Acceptance Testing
3.Automated Deployment
4.Continuous Integration
5.Issue Tracking

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

31. REPORTING
1.Code Coverage
2.Branch Coverage
3.Bug Origin:
- tested code
- untested code
4.Test/Dev Time:
- per feature
- per story

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

34. TDD DOES NOT
CREATE GOOD
a
CODE
Wait...
What ?

35. TDD DOES NOT
CREATE GOOD good plan
a
CODE good dev
good code
bad plan
bad dev
bad code

36. DISASTER RECOVERY

37. DISASTER RECOVERY
Untestable code?
Isolate and contain
-or-
Create a testable API

38. DISASTER RECOVERY
Running late?
Drop features
-or-
Test the happy path
-or-
Test core only

39. DISASTER RECOVERY
Broken build?
Fix the test
-or-
Disable the test
(or delete it)

40. DISASTER RECOVERY
Team doesn't care
Use incentives/games
-or-
Find another job
You 're worth it !

41. V QUESTIONS?
@rowan_m
i n/3218
joind.
ttp://
h
thank-you