Common Objections to TDD (and their refutations)

IBM Software Group

Common Objections to TDD

(and their refutations)
Seb Rose
Twitter: @sebrose
Blog: claysnow.blogspot.com
E-mail: seb@claysnow.co.uk
Phone: 01721 788178

© 2009 IBM Corporation

IBM Software Group | Rational software

Agenda

 Motivation
 Education
 Inappropriate project
 Cultural
 Time pressures
 Unclear benefits

2
Innovation for a smarter planet


Refutations. Really?

re·fute
/rɪˈfyut Show Spelled
/
verb (used with object), re·fut·ed, re·fut·ing.

1. to prove to be false or erroneous, as an opinion or
charge.
2. to prove (a person) to be in error.

3


TDD – in one slide

 Test First predates XP and Agile
 TDD has been around for a while
One of XP‟s core practices
Widely referenced
Still quite controversial
 I am not going to describe TDD in any detail
Red/Green/Refactor (and variants)
„T‟ for Test has unfortunate connotations
First „D‟ definitely stands for Driven
Second „D‟ may stand for Development or Design

4


5


Survey

 Simple survey ran for 3 months
Jan – Mar 2012
260 unique respondents
896 objections
 “What reasons are there not to practice TDD”
“The question wreaks of elitism - it should instead be „what reasons are
there to practice TDD‟”.
 Free text made for a wide range of responses
Harder to analyse
Split into 18 types, grouped into 5 categories

6


Results

Education
Time
Benefits
Project
Cultural

7


Breakdown

 Education (223)
Lack of Practice, Lack of Investment
 Project (194)
Domain, Legacy, Environment, Tooling
 Cultural (179)
Management, Team, Fanaticism, Demarcation, Egotism
 Time (174)
Slowness of development, maintenance and execution
 Benefits (120)
Lack of Proof & Experience, Alternatives

8


Interconnectedness of all things

 Classification is subjective
Many responses could be categorised several ways
 Respondents had different points of view
Their own objections
Objections they had heard others express
 Further analysis required
 Follow-up survey(s)

9


10


Software Crisis!
The required techniques of effective reasoning
are pretty formal, but as long as programming is
done by people that don't master them, the
software crisis will remain with us and will be
considered an incurable disease. And you know
what incurable diseases do: they invite the
quacks and charlatans in, who in this case take
the form of Software Engineering gurus.

- Dijkstra (ACM Turing Award Lecture 1972)
11


Fanaticism and Fluff

The steps of FDD are simple:
1. Take a tiny piece of fluff from the plate and put it on your
head, holding your head quite still to ensure that the fluff
does not fall off your hair.
2. Write a line of code.
3. Say, “I am the Fluff Lord, within the Dominion Of The
Fluffists.”
4. Repeat.
That’s it.
Seriously, that’s all there is to it.
12


Agenda

 Motivation
 Education
 Cultural
 Time pressures
 Wrap up

13


Hard to learn

 “TDD is hard.”

 Yes, it is
 Any technique is hard to master
Fundamental changes are hard to adopt
 10,000 hours of practice
 Did you stop trying to ride a bicycle when you fell off?

14


Where to start

 “Sheer lack of knowledge on how to approach it appropriately.
There are too many bowling examples and not enough
practicality.”

 How do you usually learn something new?
 Unit Testing skills are foundational
 Coding Dojo to practice TDD
http://cyber-dojo.com
Better used as a group, but still useful solo

15


Tests before code

 “The compiler complains if I write tests before the code”

 First step to get to green is to make the test compile
Only then can you move on to make the test pass

16


Tests will be buggy

 “Your test code is just your production code, written from the
other end (i.e. just as complex and likely to have bugs)”

 No process is infallible
“To err is human …”
 Safety in numbers
Pair programming
Peer review

17


Unfamiliar architectural style

 “How will we ever know what‟s going on if we can't see all of
the code at once?”

 TDD tends to lead to small, concise implementations
Low coupling
High cohesion
 “Proliferation” of interfaces
 Literate-ish programming

18


No design improvement

 “My observations of code from TDD-based projects show no
significant improvement in architecture, security, code
style, testability, etc. over other projects built with testing in
mind.”

 TDD ensures testability
Tendency for smaller decoupled composition
 Other design concerns (e.g. security, performance etc.) not
addressed by TDD

19


Learning several things at once

 “In a new technology, it's too difficult to learn how to TDD as
well as how to master that technology.“

 Even if you are experienced with TDD, it changes your
perspective on the new technology
Idioms
Tooling
 Kent Beck suggests reimplementing xUnit in the new
language

20


Discipline

 “TDD is a discipline and a work habit. It's very difficult to
establish the habit.”

 Habits are hard to form, but also hard to break.
 Nothing works better than positive feedback
 There are many self-help guides available 
Switch – Chip & Dan Heath
Drive – Dan Pink

21


Agenda

 Motivation
 Education
 Cultural
 Time pressures
 Wrap up

22


Too simple

 "This code is too simple to need a test“

 Then the tests will be simple too
 What‟s simple to you may be opaque to others
 As the code evolves, tests can help keep it simple

23


Just a spike

 “Because you're prototyping an idea and it's much faster to
spike without tests. If you do end up using the code then you
can write tests and refactor.”

 Use the right tool – TDD is not mandatory
 Discipline to ensure spike does not mutate
“Write one to throw away”
TDD the spike anyway!

24


Not useful for all aspects of design

 “I don't think that deriving a design by writing tests is a useful
practice. Tests by themselves cannot cover many aspects of
a design (designing for concurrency and performance in
particular by writing tests is something that I've never seen
anyone do).”

 TDD is not the only tool in the toolbox
Probably wrong tool for performance testing
Can be applied to concurrency testing (but not recommended)

25


Not useful for functional/declarative programming

 “Because it is largely adequate in imperative programming
and not when you go functional and declarative - when code
reads like specification.”

 Orthogonal.
 Absence of side effects makes testing MORE effective.

 Discuss!

26


Legacy code

 “Difficulty starting with legacy code. A simple change done
through TDD can take orders of magnitude longer due to a
need to redesign toward testability. ”

 Working Effectively With Legacy Code – Feathers
 Small, conservative steps, eventually tame fear and doubt
 Consider less intrusive approaches initially
e.g. TextTest – texttest.org

27


Insufficient tooling

 “There is no unit-test framework for the language I'm
using, and I don't have time/inclination to develop one
myself.”

 There probably is.
 You might not need one
“TDD in C” – Olve Maudal

28


GUI

 “I do a lot of UI code and don't really know how to properly do
that with TDD.”

 “Subcutaneous” testing
 Presenter First pattern
Based on MVC/MVP patterns
Very shallow view, with no business logic
Stateless presenter orchestrates interaction between view and model

29


Excessive coupling to data

 “A test expresses a unit of change as data that fits the needed
computation. Creating that data is harder than writing the
program that accomplishes the change.”

 Unit tests preferably utilise „small‟ amounts of data
 For domains where this is not possible
You will need large amounts of data irrespective of test approach
Bootstrap process with constructed data
Continue with captured data

30


Agenda

 Motivation
 Education
 Cultural
 Time pressures
 Wrap up

31


Management antipathy

 “Management want results NOW; very much willing to clean
up small oversights later. 'Close is good enough' attitude.”

 Management are generally result focused
 Previous bad experiences affect appetite for change
Both ways!
 Start small
Need to demonstrate benefit to „bottom line‟

32


Team resistance

 “Teammates are not prepared. They do not have enough
knowledge or experience in unit testing.”
 “No one tells me how to program!”

 Changing behaviours is hard
“Fearless Change” has many patterns for introducing change

33


I never make mistakes

 “I already know what the code needs to do and it's low risk. I
don't need a test for it.”
 “My first design idea is always perfectly good.”
 “My code always works the first time.”

 Do people really believe this?
 Even if they do, is everyone that ever touches the code going
to be so talented?

34


Testing is for testers

 “We don't need TDD, we've got a QA department. They'll find
the bugs for us.”

 TDD is not just about testing
Drives design
Refactoring/regression safety net
 Write tests to explore EVERY defect you find
Living documentation
 Helps future developers understand intended behaviours

35


All TDD-ers are fanatics

 “It has become a cult. Its advocates have made it antithetical
to „Individuals and interactions over processes and tools‟. It is
evangelized through coercion and browbeating --
necessarily, as it isn't compelling on it's own.”
 “Someone needs to tell unclebob that he might be right, but
he's part of the problem - to non-modern coders (which felt
like the majority last time I looked) he comes across like a
raving loony.”

36


Fluff (continued)

If at any time you even THINK about writing a line of code
before putting fluff on your head, then you‟ve to delete all your
code, shake all the fluff from your head onto the plate and start
all over again.
I have been practicing FDD for 12 years now; sometimes in the
office, I have so much fluff on my head that my boss thinks I‟m
a hay-stack, only made of fluff. A sort-of fluff-stack, if you will.
But one thing is beyond doubt: the code I write, when I‟m in this
fluff-zone, is the most high-quality code that anyone has ever
seen.

37


Agenda

 Motivation
 Education
 Cultural
 Time pressures
 Wrap up

38


More code to write

 “Takes too much time to write test.”

 How will your code get tested?
Test team?
Customers & Stack Trace Driven Development?
 How much time will be spent figuring out how to make
changes later?
 What proportion of your time do you actually spend coding?

39


More code to maintain

 “If I change something it will break a whole bunch of tests that
I will have to fix and it will be more work for me in the end
than just verifying my changes manually.”

 It is USEFUL to know when behaviour changes
 Foundational Unit Testing skills reduce brittleness
next 6 slides

40


Testability
 Testability needs to be designed in
TDD ensures code is testable
 Code with hidden dependencies is hard to test
Dependency Injection/Inversion
 Pass dependencies into code under test
 Write factories that permit injection of test doubles
Interfaces should be cohesive
 Wide interfaces encourage unnecessary coupling
Avoid globals, singletons etc.
 Retro-fitting unit tests is hard
Take small steps
Introduce a „seam‟ – c.f. Working Effectively with Legacy Code

41


Necessity
 Test observable behaviour
Don‟t modify encapsulation to aid testing
If a behaviour isn‟t observable through the public interface what is it for?
 Don‟t slavishly write one test per method
Test behaviours
Some methods may not need any dedicated tests
Methods that implement useful behaviours may need many tests
 Choose test variants carefully
Edge conditions
Invalid inputs
Multiple invocations
Error signalling

42


Granularity
 Test a SINGLE observable behaviour
It is tempting to combine related behaviours in a single test – DON‟T
 … even if EXACTLY the same steps are needed
public void shouldSortTwoStringsAndReportCorrectSize() {
SortedSet<String> animals = new TreeSet<String>();
animals.add(“Zebra”);
animals.add(“Anteater”);

assertEquals(2, animals.size());
assertEquals(“Anteater”, animals.first());
assertEquals(“Zebra”, animals.last());
}

43


Understandability
 Name tests to describe the behaviour under test
Describe nature of the test
 Is it checking that preconditions are enforced?
 Is a dependency going to signal an error?
Long names are fine – you only type them once
Be precise
 shouldReturnCorrectValue is not a good name for a test
 shouldReturnCorrectSumOfTwoIntegersWithoutOverflow
 should_return_correct_sum_of_two_integers_without_overflow
 When a test fails you want to know WHAT WENT WRONG
You don‟t want to reverse engineer the test
You don‟t want to run smaller tests to isolate the failure

44


Maintainability
 Unit Tests should be written to same quality as Production code
Tests will be maintained and read just as often as production code
Code is communication to other developers not just a compiler
 Organise tests into cohesive suites
 Refactor tests to avoid duplication
Use suites to perform common set up/tear down operations
Extract common code into methods
Extract common functionality into classes
 Remove redundant tests

45


Reiteration: 5 -ities

 Testability
 Necessity
 Granularity
 Understandability
 Maintainability

 MUNGT ?
 TeNGUM?

46


Mock-based tests rot

 “Unit-test mock/stub assumptions rots”

 Use collaboration and contract tests – J.B. Rainsberger
Collaboration tests make assumptions about the contract; contract tests
try to justify those assumptions
A stub in a collaboration test must correspond to an expected result in a
contract test
An expectation in a collaboration test must correspond to an action in a
contract test

47


That library is third party

 “API layers above and below you don't provide adequate
mocks. Testing against the „real thing‟ is hard/impossible.”

 “Don't mock types you don't own” – Joe Walnes
 Write adapters that provide a domain specific API
 Write acceptance tests that verify the library‟s behaviour
Run whenever adopting a new version

48


Slow execution

 “Running the tests takes too long.”

 For TDD to work tests need to (build and) execute in seconds
 Some environments need careful configuration
C/C++
Rails
 Are they really Unit Tests? (See next slide)

49


A test is not a unit test if:

 It talks to the database
 It communicates across the network
 It touches the file system
 It can‟t run at the same time as other unit tests
 You have to do special things to your environment (such as
editing config files) to run it
(Michael Feathers‟ blog, 2005)

50


Agenda

 Motivation
 Education
 Cultural
 Time pressures
 Wrap up

51


Absence of research

 “No scientific proof of it actually having any benefit (compared
to just code reviews, pair programming or etc.) for the same
amount of time”
 “It's not practical for the kind of work I do. By which I mean, it
cannot be conclusively shown to provide tangible benefits that
outweigh the perceived costs.”
 “In an industry where todays must have offering is tomorrows
dustbin liner, it's often prudent to wait before trying the latest
snake oil!”

52


Absence of research (cont.)

 “We found that test-first students on average wrote more tests
and, in turn, students who wrote more tests tended to be
more productive. We also observed that the minimum quality
increased linearly with the number of programmer
tests, independent of the development strategy employed.”

On the Effectiveness of Test-first Approach to Programming
Proceedings of the IEEE Transactions on Software Engineering 2005
 Lots of other papers are referenced from:
http://bradapp.blogspot.co.uk/2009/08/studies-on-effectiveness-of-tdd.html

53


Our process is good enough already
 “My team doesn't practice it. It is difficult to change existing
practices if they seem to work reasonably well.”
 “I've personally been a part of four 'large' software projects
where active pursuit of a test suite was in play. None of the
four projects ever launched into production. The people I
worked with were smart and highly ambitious, yet they (we)
failed to launch.
 “I've personally been a part of dozens of software projects
where active pursuit of a test suite was NOT in play. Most
every one of those projects launched into production in a
timely manner.”

54


Test after

 “It's easier to write the code first and the test after.”
 “Writing tests after code is just as good.”
 “Writing tests before code doesn't make sense.”

 Testability
Rework needed if code not testable
 Discipline
Will you really write the tests later?

55


BDD

 “Why practice TDD when you can practice BDD?”

 BDD extends TDD
 Involves stakeholders, not just developers
Even harder to implement.

56


ATDD, BDD, GOOS

 Many shades of outside-in, test-first development

57


None of these are enough either
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then check that the account is debited
And check that cash is dispensed
And check that the card is returned

“And check that nothing happens that shouldn’t happen and
everything else happens that should happen for all variations
of this scenario and all possible states of the ATM and all
possible states of the customer’s account and all possible
states of the rest of the database and all possible states of the
system as a whole, and anything happening in the cloud that
should not matter but might matter.”

58


Manual testing

 “It is much faster to just think about the proper
implementation, write the code and manually test it.”

 Until you need to do it again
 … and again
 Manual scripts
Error prone
Time consuming
Expensive

59


Agenda

 Motivation
 Education
 Cultural
 Time pressures
 Wrap up

60


Not sufficient, but necessary?

 TDD is not enough. Consider:
Acceptance
Usability
Performance / Stress
Exploratory
 Systems have been, and continue to be, successfully
delivered without TDD.
But they have also been delivered without designs, documentation, or
…. testing of any kind.

61


Conclusions

 There are many impediments to adopting TDD
 Benefits are not universally accepted
 TDD is not a “Silver Bullet”

62


Essential Reading

 Test Driven Development by Example – Kent Beck
 Growing Object Oriented Software Guided By Tests – Steve
Freeman/Nat Pryce
 Working With Legacy Code – Michael Feathers
 Fearless Change – Mary Lynn Manns/Linda Rising
 JUnit Recipes – J.B. Rainsberger

63


Other references

Fluff Driven Development:
http://www.threeriversinstitute.org/blog/?p=594
Presenter First:
http://atomicobject.com/files/PresenterFirstAgile2006.pdf
TDD in C:
http://www.pvv.org/~oma/TDDinC_Smidig2007.pdf
On the effectiveness of Test-first approach to Programming:
http://nparc.cisti-icist.nrc-
cnrc.gc.ca/npsi/ctrl?action=rtdoc&an=5763742&article=0&lang=
en&ext=pdf
64

Common Objections to TDD (and their refutations)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Common Objections to TDD (and their refutations)

Semelhante a Common Objections to TDD (and their refutations) (20)

Mais de Seb Rose

Mais de Seb Rose (20)

Último

Último (20)

Common Objections to TDD (and their refutations)

Notas do Editor