Pragmatic notdogmatictdd

Joseph W. Yoder

Pragmatic, Not
Dogmatic TDD:
Rethinking How We Test

Joseph W. Yoder
The Refactory, Inc.
joe@refactory.com
http://www.refactory.com

Bio
Joseph Yoder (Founder and Architect, The Refactory;
Hillside Board President; Long Term ACM Member)
pattern enthusiast, author of Big Ball of Mud;
programs adaptive software,
runs a development company,
consults top companies on software
needs, agile enthusiast,
amateur photographer,
motorcycle enthusiast,
enjoys dancing samba!!!

Pragmatic Test Driven Development – Copyright © 2012 Joseph W. Yoder The Refactory, Inc. Slide - 2

TDD & Testing Best Practices Page - 1

Joseph W. Yoder


Test-Driven Development Cycle



Joseph W. Yoder

Add a Test
design class interface +
define expected behavior

Make Test Pass
create actual behavior +
most simple solution

Refactor
clean implemented code
+ adjust class design

First
Classic Test-Driven Development
Start
test fails Write
Re(Write) Check if production
a test test fails code
1 or more
tests fail

test succeeds
all tests
Clean up code succeed Check
all tests
(Refactor) succeed

Ship Ready to
it!!! Release?
Short Sprints


Joseph W. Yoder

TDD Promises
1 Tests help you build the right thing
2 Tests guide development
3 Tests keep you focused
4 Tests allow you to change
code safely and quickly
5 Tests ensure what you build works
6 You will end up with quality code
7 You will end up with a good design

Question: Do tests help you
build the right things?



Joseph W. Yoder

Common Misperceptions
Tests verify program correctness
 3.1415926535…

Tests enable and encourage
well-designed code


Understanding
Tests



Joseph W. Yoder

Test Target → the thing
T we are trying to test.

Action → changes environment
or the Test Target.

Assertion → comparison of
expected vs observable outcome
of the action on the Test Target.

Test → a sequence
of at least one action
and one assertion

T T’



Joseph W. Yoder

Good Test Outline
1. Set up
2. Declare the expected results
3. Exercise the test
4. Get the actual results
5. Assert that the actual results
match the expected results


Testing Questions
What is a good size for a test?
 a class?
 a set of classes?
 a set of interacting functions/methods?

What is important to test?



Joseph W. Yoder

What to Test
Significant scenarios of use, not
isolated methods.
The difficult parts: Complex interactions,
intricate algorithms, tricky business logic
Required system qualities
 Performance, scalability,
throughput, security...
How services respond to normal
and exceptional invocations.

What Not to Test
Tests should add value,
not just be an exercise.
Do not test:
 setters and getters
(unless they have side effects or are very complex)
 every boundary condition; only test
those with significant business value
 every exception; only those likely to occur
or that will cause catastrophic problems.


Joseph W. Yoder

Question: Do tests help you
build the right things?

Answer: Yes. But only if you
have the right tests, not
superficial tests.


Ten Commandments of Testing
1. Test single complete scenarios
2. Do not create dependencies between tests
3. Only verify a single thing in each assertion
4. Respect class encapsulation
5. Test limit values and boundaries
6. Test expected exceptional scenarios
7. Test interactions with other objects
8. When you find a bug, write a test to show it
9. Do not duplicate application logic in tests
10. Keep your test code clean



Joseph W. Yoder

Question: Do tests guide
development and keep you
focused?


Two Faces of Testing
Defining tests But you may
helps limit be missing
scope and the bigger
increases focus picture…
Tests force you Might need to
to implement consider how
functionality current
instead of functionality
jumping around affects the
and tweaking rest of the
stuff system


Joseph W. Yoder

Thinking Fast vs. Slow
Fast thinking:
decisions based on
intuition, biases,
ingrained patterns,
and emotions

Slow thinking:
Reasoning, logical
thinking

Take Time For Both
Slow thinking
 Pairing and discussion options are
why you want to implement something
a certain way
 Sketching, noodling, design spikes
Fast thinking
 Fast turns of coding, testing and
quick fixes… (Red/Green)



Joseph W. Yoder

You are not
doing TDD! Common Belief
You must create
You are not
your tests first! practicing TDD
correctly
unless you
write tests
first, before
writing any
code that is
tested.

Dogmatic
 Synonyms: assertive, bullheaded, categorical,
definite, despotic, determined, dictative,
doctrinaire, domineering, downright, fanatical,
intolerant, narrow-minded, one-sided, overbearing,
peremptory, stubborn, tyrannical, unequivocal

 Antonyms: amenable, flexible, manageable

Blindly following the TDD doctrine says you …
“Must” write your test first!!!



Joseph W. Yoder

Is it OK to write tests after
you write production code?
Is this cheating?
Does this result in bad code?
Does it result in a bad design?
Does it reinforce “slacker”
tendencies to not write tests?


Pragmatic
 Synonyms: businesslike, common, commonsense,
down-to-earth, easy, efficient, hard, hardboiled,
hardheaded, logical, matter-of-fact, mundane, no-
nonsense, practical , rational, realistic, sane,
sensible, sober, unfantastic, unidealistic,
unsentimental

 Antonyms: idealistic, unrealistic

Sometimes it is more practical and logical to write
your tests after you write the code!!!



Joseph W. Yoder

Common Practice
Tests don’t always get written first.
Start
test fails Write
Re(Write) Check if production
a test test fails code

1 or more
tests fail
test succeeds
all tests
Clean up code succeed Check
all tests
(Refactor) succeed

Ship Ready to
it!!! Release?

A Pragmatic Testing Cycle
Tests verify that code works as expected.
Tests don’t always guide what code you write.
Write some Check if
Re(write)
production test fails
a test
code

Clean up code
(Refactor) 1 or more
tests fail Check
all tests succeed all tests
succeed
Ship Ready to
it!!! Release?


Joseph W. Yoder

Pragmatic Testing Cycle
Alternate between writing
test code and production
in small steps.
Use feedback from tests
to verify code (integrate often).
Don’t worry whether the chicken or
the egg comes first. Sometimes
development guides testing.
Do what yields the most value!

Question: Do tests guide
development and keep
you focused?
Answer: Yes if you have the
right tests. But tests do not
tell you if you built it right.
Sometimes you need to take
a broader look.


Joseph W. Yoder


Question: Do tests allow you
to change code safely and
quickly?



Joseph W. Yoder

Test-Driven Refactoring
Development

Common Wisdom
Work refactoring into your daily routine.

“In almost all cases, I’m opposed to setting aside time
for refactoring. In my view refactoring is not an activity
you set aside time to do. Refactoring is something you
do all the time in little bursts.”—Martin Fowler



Joseph W. Yoder

Testing is Key!!!


Two Refactoring Types*
Floss Refactorings—frequent,
small changes, intermingled
with other programming
(daily health)

Root canal refactorings—
infrequent, protracted
refactoring, during which
programmers do nothing
else (major repair)
* Emerson Murphy-Hill and Andrew Black in
“Refactoring Tools: Fitness for Purpose”
http://web.cecs.pdx.edu/~black/publications/IEEESoftwareRefact.pdf


Joseph W. Yoder

Sometimes it is easier to
throw away tests, change the
design of your production
code, and then write new
tests.


The design of test code
needs to evolve, just like
production code!



Joseph W. Yoder

….if your tests slow down
your ability to make the
changes you want to make
in production code, rethink
whether you want to keep
all your tests.


Refactoring Test bar should
Production Code continue green

But tests can also
have smells!



Joseph W. Yoder

Possible Duplicate Code


So, Refactor the Tests!

Create Test
Hierarchy

Pull Up
Common
Parts



Joseph W. Yoder

Additional Test
Refactorings
Tests have Refactorings
that are specific to test
code …

Test Method
Refactorings
Replace actions & assertions
with simpler equivalent ones:
Add Assertion Explanation
Introduce Assertion Method

Simplify Test Scenario

Separate Action from Assertion

Decompose Assertion


Joseph W. Yoder

Test Class
Refactorings
Reorganize actions and assertions
to reduce duplication:
Add Fixture
Introduce Initialization Method

Inline Initialization Method

Join Incremental Tests

Split Test

Join Similar Tests with Distinct Data

Question: Do tests allow
you to change code safely
and quickly?
Answer: Yes and no. It takes
courage to throw away and
rewrite your tests.


Joseph W. Yoder

Classic Test-Driven
Development Rhythm
User story-by-story:
 Write the simplest test
 Run the test and fail
 Write the simplest code
that will pass the test
 Run the test and pass
Repeat until a “story”
is tested and
implemented
“Design happens
between the
keystrokes”


Question: Do tests help with
quality code and good design?



Joseph W. Yoder

Another View of
Test-Driven Development
Requirements Architecture
Envisioning Envisioning Conceptual Modeling
(days/weeks/...) (days/weeks/…)
Iteration 0: Envisioning

Iteration Modeling
(hours)
a little bit of modeling
Model Storming then a lot of coding
(minutes)

Fast
TDD(hours)
Iteration n: Development

Spike Solutions
If some technical difficulty
threatens to hold up the
system's development,
Or you are not sure how to
solve a particular problem…
“Put a pair of developers on the
problem for a week or two to
reduce the potential risk”



Joseph W. Yoder

Pragmatic Testing Questions
What are the most important kinds
of testing you should focus on?
Who should write them?
Who run them?
When are they run?
How are they run?


Different Kinds of Tests
Unit Tests – Tests classes and components
Integration Tests – Tests code integration
Smoke Tests – Quick tests of core functionality
Performance Tests – Test system under load
Regression Tests – Tests it is still working
Acceptance Tests – Requirements testing
System Tests – Test all parts together

Common to only focus on Unit Tests in TDD!!!


Joseph W. Yoder

Tests Can Overlap…

Smoke
Tests Quality
Scenario
Integration
Tests Acceptance
Tests
(Functional and
qualities)
Unit
Tests


TDD should be more than…
Developing unit tests along with code

Only checking in tested code with unit
tests + defining some customer
acceptance



Joseph W. Yoder

Other Techniques for
Improving Quality
Steve McConnell
http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/


Combine and Conquer
The average is 40% for
any one technique…
No one approach is adequate
Combining techniques gives
you much higher quality



Joseph W. Yoder

Question: Do tests help with
quality code and good design?

Answer: They can but …
you need more than tests.


The Agile Dream …

Identify some Create some Construct based
requirements acceptance criteria on the tests

Deliver some working Test to verify the
software requirements


Joseph W. Yoder

Agile Design Values
Core values:
 Design Simplicity
 Communication
 Teamwork
 Trust
 Satisfying stakeholder needs
Keep learning
Lots of Testing!!!


Pragmatic Test-Driven
Development (core process)
Tests written & must pass before checking in production code

Write some Check if
Re(write)
production test fails
a test
code

Clean up code
(Refactor) 1 or more
tests fail Check
all tests succeed all tests
succeed
Ship Ready to
it!!! Release? Short Sprints


Joseph W. Yoder

TDD Challenges
1. Lot’s of Unit Tests with classic TDD is
not enough to guarantee good design…
Dogmatic TDD can focus on functionality and features rather than design

2. Deception that incremental test mode will give you
an inductive way to prove it works…probably more
deductive and example driven…
All squirrels I see in Illinois are brown, therefore all squirrels are brown….

3. TDD or unit tests can hurt the evolution/refactoring
phase….“Oh no! Changes might break the tests”
4. Not enough Quality Tests are written. Focus often is
on function and missing quality.
5. Testing Patterns of Collaboration are important,
Unit tests on class might not be good enough.
Setting up Mocks doesn’t really test collaborations.

Pragmatic Test Driven
Development Is…
Practical…
 Focus on how testing best fits into and enhances
your current software development practices.
Thinking carefully about how best to validate
that your software meets its requirements.
Developing the optimum set of tests to feel
confident your system keeps working, not
just Unit Testing!
Including both slow and fast
thinking with your tests.


Joseph W. Yoder

Keep It Focused
Keep It Fresh
Expand your Horizons

…Be Practical


Where Did All The Time Go?
Muito Obrigado!!!

rebecca@wirfs-brock.com joe@refactory.com
Twitter: @rebeccawb Twitter: @metayoda

http://refactory.com/training/test-driven-development
http://adaptiveobjectmodel.com/2012/01/what-is-pragmatic-tdd/


Joseph W. Yoder

Minimum Bar for
Pragmatic TDD
All production code must
have tests validating it.
Think about tests early in each iteration
and how to validate the next release.
Core tests include important
aspect of your software,
what you really care about.
Include both slow and fast
thinking with your tests.

Ten Tenets of Testing
1. Test single complete scenarios
2. Do not create dependencies between tests
3. Only verify a single thing in each assertion
4. Respect class encapsulation
5. Test limit values and boundaries
6. Test expected exceptional scenarios
7. Test interactions with other objects
8. When you find a bug, write a test to show it
9. Do not duplicate application logic in tests
10. Keep your test code clean



Pragmatic notdogmatictdd

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (10)

Similar to Pragmatic notdogmatictdd

Similar to Pragmatic notdogmatictdd (20)

Recently uploaded

Recently uploaded (20)

Pragmatic notdogmatictdd