Intro To Tdd Agile Palooza

Introduc)on
to

Test-‐Driven
Development
Driving
So7ware
Design
through
Programmer
Tests

Chris
Sterling
Technology
Consultant,
Cer)ﬁed
Scrum
Trainer,
and
Agile
Coach

Friday, February 5, 2010

Agenda

• Test-‐Driven
Development
(TDD)
– The
“Flow”
– Integra)ng
with
Team
• Reasons
for
TDD
• Diﬃcul>es
with
TDD
• Example
TDD
Session
• Refactoring

2
Copyright © 2010 Sterling Barton. All rights reserved.


Ques>ons
for
You...

• How
many
of
you
are
prac>cing
TDD?
• What
issues
are
you
having
currently
with
TDD?

3


Test-‐Driven
Development

Basic
“Flow”
and
Constructs
of
TDD

4


TDD
-‐
Basic
“Flow”

5


TDD
-‐
Basic
“Flow”

Write

Failing
Test

5


TDD
-‐
Basic
“Flow”

Write

Failing
Test

Make
Test

Pass

5


TDD
-‐
Basic
“Flow”

Write

Failing
Test

Refactor
to
Make
Test

Acceptable

Design Pass

5


Steps
of
TDD
“Flow”

1. Write
a
programmer
test
2. Run
the
programmer
test
and
it
should
fail
(red
bar)
3. Write
just
enough
code
to
make
failing
test
pass
4. Run
programmer
test
successfully
(green
bar)
5. Refactor
code
to
an
acceptable
design
(green
bar)

RISK:
Pushing
out
refactoring
to
add
more
code
ﬁrst.

Don’t
forget
to
refactor
frequently
to
an
acceptable

design.

6


Be
a
User
-‐-‐
“What
should
the
so^ware
do
next
for

me?”
This
ques>on
helps
you
to
decide
what
the

next
programmer
test
should
model

7


Test-‐Driven
Development

Integra>ng
with
Teams

8


Integra>ng
with
Team

9


Integra>ng
with
Team

Write

Failing
Test

9


Integra>ng
with
Team

Make
Test

Pass

Write

Failing
Test

9


Integra>ng
with
Team

Make
Test

Pass

Write
Integrate

Failing
Test with
Team

9


Integra>ng
with
Team

Make
Test

Pass

Write
Refactor
to

Integrate
Acceptable

Failing
Test with
Team Design

9


Need-‐Driven
Design

10


Test-‐Driven
Development

Why
Is
TDD
Important?

11


Accrual
of
Quality
Debt



Break/Fix
Only
Prolongs
It



Eﬀect
of
Project
Constraints
on
Quality

14


Managing
So^ware
Debt
–
an
Overview
Effect of Managing Software Debt
over time is extended preservation
of software’s value
Higher Software Value

De
pr Potential for
Val eciat
So ue D ion o depreciation is
ftw u
are e to f always there so
De
bt discipline is
essential

Minimum
Acceptable
Value

Time



Acceptance
Test-‐Driven
Development

Functional Implement
Requirement Functionality

Execute
Draft Acceptance
Test Cases
Acceptance
Test Cases
Review
Results
Verify Results
Accepted

Modify Acceptance
Test Cases
16


Con>nuous
Integra>on

17


Test-‐Driven
Development

What
Causes
TDD
to
be
so
Diﬃcult
to

Implement
Well?

18


Impediments
to
TDD

This
simple
technique
for
developing
so^ware,
when

used
in
a
disciplined
manner,
will
enable
individuals

and
teams
to
improve
so^ware
quality.
The
discipline

necessary
to
do
TDD
is
not
easily
aeainable.
Following

is
a
list
of
environmental
issues
that
lowers
chances
of

eﬀec>vely
implemen>ng
TDD
approach.

19


Schedule
Pressure

Pressure
from
management
and

stakeholders
to
release
based
on
an

unreasonable
plan.
Integrity
of
the
so^ware

is
always
sacriﬁced
when
the
plan
is

inﬂexible
and
unwilling
to
incorporate

20


Lack
of
Passion

Lack
of
passion
for
learning
and

implemen>ng
TDD
eﬀec>vely
on
Team.

The
amount
of
discipline
required
makes

passion
extremely
helpful.

21


Insuﬃcient
Experience

Insuﬃcient
team
member
ra>o
who
have

experience
doing
TDD
well.
When
there
is

liele
experience
on
or
coaching
for
the

team
success
is
minimal.

22


Legacy
Code

If
the
so^ware’s
design
is
poor
or
is
diﬃcult
to

test
then
ﬁnding
a
star>ng
point
could
seem

impossible.
If
legacy
code
is
large
and
contains

no,
or
only
minimal,
test
coverage
then

disciplined
TDD
will
not
show
visible
results
for

some
>me.
23


Introducing
TDD
Approach
Eﬀec>vely

To
successfully
adopt
TDD,
it
is
important
to

manage
these
environmental
issues.
This
could

include
managing
expecta>ons,
providing
the

Team
support
from
a
coach,
and
enabling

suﬃcient
learning
of
tools
and
techniques

while
working
with
an
exis>ng
code
base.
24


Test-‐Driven
Development

Quick
Example

25


Jieer
–
Example
TDD
Session

• Fake
micro-‐blogging
tool
named
“Jieer”
is
made
by

Seaele-‐based
ﬁc>>ous
company
that
focuses
on

enabling
coﬀee
injected
folks
to
write
short
messages

and
have
common
online
messaging
shorthand

expanded
for
easy
reading.
The
user
story
we
are

working
on
is:
So
it
is
easier
to
read
their
kid’s
messages,
Mothers
want

to
automa>cally
expand
common
shorthand
nota>on
• The
acceptance
criteria
for
this
user
story
are:
– LOL,
AFAIK,
and
TTYL
are
expandable
– Expand
lower
and
upper
case
versions
of
shorthand
26


Expand
LOL
to
“laughing
out
loud”

public class WhenUsersWantToExpandMessagesThatContainShorthandTest {
@Test
public void shouldExpandLOLToLaughingOutLoud() {
JitterSession session = mock(JitterSession.class);
when(session.getNextMessage()).thenReturn("Expand LOL please");
MessageExpander expander = new MessageExpander(session);
assertThat(expander.getNextMessage(),
equalTo("Expand laughing out loud please"));
}
}

public class MessageExpander {
public String getNextMessage() {
String msg = session.getNextMessage();
return msg.replaceAll("LOL", "laughing out loud");
}

27


But
wait…what
if…?

• What
if
LOL
is
wrieen
in
lower
case?
• What
if
it
is
wrieen
as
“Lol”?
Should
it
be
expanded?

• What
if
some
varia>on
of
LOL
is
inside
a
word?
• What
if
characters
surrounding
LOL
are
symbols,
not
leeers?

Write
these
down
as
upcoming
programmer
tests
as
comments
so
I

don’t
forget
them.

// shouldExpandLOLIfLowerCase
// shouldNotExpandLOLIfMixedCase
// shouldNotExpandLOLIfInsideWord
// shouldExpandIfSurroundingCharactersAreNotLetters

28


Expand
LOL
If
Lower
Case

@Test
public void shouldExpandLOLIfLowerCase() {
when(session.getNextMessage()).thenReturn("Expand lol please");
equalTo("Expand laughing out loud please"));
}

This
forced
use
of
java.u1l.regex.Pa6ern
to
handle
case
insensi1vity.
return Pattern.compile("LOL”, Pattern.CASE_INSENSITIVE)
.matcher(msg).replaceAll("laughing out loud");
}

29


Don’t
Expand
“Lol”
–
Mixed-‐Case

@Test
public void shouldNotExpandLOLIfMixedCase() {
String msg = "Do not expand Lol please";
when(session.getNextMessage()).thenReturn(msg);
assertThat(expander.getNextMessage(), equalTo(msg));
}

This
forced
me
to
stop
using
Pa6ern.CASE_INSENSITIVE
ﬂag
in

pa6ern
compila1on.
Only
use
“LOL”
or
“lol”
for
replacement

criteria.
return Pattern.compile("LOL|lol").matcher(msg)
.replaceAll("laughing out loud");

30


Don’t
Expand
“LOL”
If
Inside
Word

@Test
public void shouldNotExpandLOLIfInsideWord() {
String msg = "Do not expand PLOL or LOLP or PLOLP please";
when(session.getNextMessage()).thenReturn(msg);
assertThat(expander.getNextMessage(), equalTo(msg));
}

The
pa6ern
matching
is
now
modiﬁed
to
use
spaces
around
each

varia1on
of
valid
LOL
shorthand.
return Pattern.compile("sLOLs|slols").matcher(msg)

31


Expand
“LOL”
If
Not
Inside
Word

@Test
public void shouldExpandIfSurroundingCharactersAreNotLetters() {
when(session.getNextMessage()).thenReturn("Expand .lol! please");
equalTo("Expand .laughing out loud! please"));
}

The
ﬁnal
implementa1on
of
pa6ern
matching
code
looks
as
follows.
return Pattern.compile("bLOLb|blolb").matcher(msg)

32


Test-‐Driven
Development

Refactoring

33


Merciless
Refactoring

• Refactoring:
a
disciplined
technique
for
restructuring
an

exis>ng
body
of
code,
altering
its
internal
structure

without
changing
its
external
behavior.*

• Merciless:
having
or
showing
no
[mercy
-‐
showing
great

kindness
toward
the
distressed]

• Relieve
your
distressed
code
through
kindness
and

disciplined
restructuring

* From http://www.refactoring.com/
34


Where
to
Start
Refactoring?

• Does
this
change
directly
affect
feature
I
am
working

on?
• Would
change
add
clarity
for
feature
implementa>on?
• Will
change
add
automated
tests
where
there
are

none?
If
“yes”
to
any
ques>on
above,
ask
following
ques>on
to

decide
if
you
should
work
on
it
now:
• At
first
glance,
does
refactoring
look
like
a
large

endeavor
involving
significant
por>ons
of
the
so^ware’s

components?
35


When
to
Stop
Refactoring?

• Am
I
refactoring
code
not
directly
affected
by
feature?
• Is
other
code
directly
affected
by
feature
I
am
working
on

that
has
not
been
refactoring
sufficiently?
• If
refactoring
is
exploding
feature
es>mate
given
to

Customer
then
I
should
bring
it
up
to
Team
to
decide
how

we
should
progress
• If
Team
decides
that
refactoring
can
be
absorbed
into

current
itera>on
without
affec>ng
delivery
on
our

commitments
then
con>nue
refactor
• If
refactoring
affects
commitments
then
bring
it
to

Customer
for
discussion
how
to
proceed
36


Automate
Tes>ng
to
Support
Refactoring

• Refactoring
cannot
be
done
eﬀec>vely
without

automated
tests
surrounding
code

• Start
by
crea>ng
automated
test
which
fails

• If
diﬃcult
to
create
at
unit
level
look
at
automated

acceptance
tests
from
func>onal
perspec>ve
• Over
>me
look
for
ways
to
create
automated
unit
tests

37


Automated
Tests

Application

38


Automated
Tests

Application

New
Feature

38


Automated
Tests

Application

New Design Changes
Feature

38


Automated
Tests

Application

Automated
New Design Changes Regression
Test Run
Feature

38


Principles
of
Agile
So^ware
Quality

• The
system
always
runs

• No
code
is
wrieen
without
a
failing
test

• Zero
post-‐itera>on
bugs

* From “Flawless Iterations” presented by Alex Pukinskis at Agile 2005

39


Thank
you

Ques>ons
and
Answers

40


Chris
Sterling
• Technology
Consultant,
Cer>ﬁed
Scrum

Trainer
and
Agile
Coach
at
Solu>onsIQ
• Consults
on
so^ware
technology
across
a

spectrum
of
industries
• Consults
organiza>ons
on
Agile

development,
management,
and

enterprise
prac>ces
• Founder
of
Interna>onal
Associa>on
of

So^ware
Architects
(IASA)
Puget
Sound

chapter
• University
of
Washington
Lecturer:
Agile

Developer
Cer>ﬁcate
Program
• Email:
CSterling@Solu>onsIQ.com
• Blog:
hep://chrissterling.gepngagile.com

41


Intro To Tdd Agile Palooza

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (16)

Mehr von Chris Sterling

Mehr von Chris Sterling (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Intro To Tdd Agile Palooza