See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221321805

Discipline and practices of TDD: (test driven development).

Conference Paper · January 2003

DOI: 10.1145/949344.949407 · Source: DBLP

CITATIONS READS
26 772

7 authors, including:

Steven D. Fraser Dave Astels

Innoxec (Innovation Executive Services) SteelSeries
120 PUBLICATIONS   342 CITATIONS    7 PUBLICATIONS   308 CITATIONS   

SEE PROFILE SEE PROFILE

Barry Boehm John Mcgregor

University of Southern California Clemson University
381 PUBLICATIONS   24,254 CITATIONS    218 PUBLICATIONS   3,352 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Systems Quality Ontology, Tradespace, and Affordability View project

MULTIPLE: Multimodeling Approach for Quality-Aware Software Product Lines View project

All content following this page was uploaded by Steven D. Fraser on 21 May 2014.

The user has requested enhancement of the downloaded file.

 Panel
Discipline and Practices of TDD
(Test Driven Development)
Steven Fraser (Chair) Dave Astels
Independent Consultant Adaption Software
Barry Boehm John McGregor
USC Clemson University
ABSTRACT
This panel brings together practitioners with experience in Agile
and XP methodologies to discuss the approaches and benefits of
applying Test Driven Development (TDD). The goal of TDD is
clean code that works. The mantra of TDD is: write a test; make it
run; and make it right. Open questions to be addressed by the
panel include: – How are TDD approaches to be applied to data-
bases, GUIs, and distributed systems? What are the quantitative
benchmarks that can demonstrate the value of TDD, and what are
the best approaches to solve the ubiquitous issue of scalability?
Categories & Subject Descriptors:
D.2.4 Software/Program Verification
D.2.5 Testing and Debugging
D.2.10 Design Methodologies
General Terms: Design, Management
Keywords: TDD, Test-Driven Design, XP Practices,
Refactor, Inspections
1. Steven Fraser, sdfraser@acm.org
Steve Fraser consults on software engineering and technology
transfer best-practices in Santa Clara, California. Until 2002,
Steve served fifteen years in a variety of diverse software tech-
nology program management roles at Nortel Networks including:
Process Architect, Senior Manager (Disruptive Technology),
Process Engineering Advisor, and Software Reuse Evangelist.
Steve served as the initiator, Chair, and Event Director of the
Nortel Networks Design Forum, a proprietary global technology
transfer event run by video, audio and web conferencing. In 1994
he served a year as a Visiting Scientist at the Software Engineer-
ing Institute (SEI) collaborating with the Application of Software
Models project on the development of team-based domain analy-
sis techniques. Steve is an avid operatunist and videographer.
2. Dave Astels, david@adaptionsoft.com
Dave Astels has built hardware and software systems for over 20
years, and used OO technologies for the last 12 years. Dave has
studied, practiced, taught, evangelized, and coached XP and Agile
Processes since 1998. He is a co-author of A Practical Guide to
eXtreme Programming, and author of Test-driven Development: A
Copyright is held by the author(s)/owner(s).
OOPSLA’03, October 26-30, 2003, Anaheim, California, USA.
ACM 1-58113-751-6/03/0010.
268
Kent Beck
Three Rivers Institute
James Newkirk Charlie Poole
Microsoft Poole Consulting
Practical Guide, both published by Prentice Hall. Dave edits the
Test-Driven Development Edition of The Coad Letter and is a
Founding Partner at Adaption Software, Inc.
Test-driven Development (TDD) is one of the few XP practices
that have stand-alone benefits. Indeed, it is an enabler for several
other XP practices, e.g. refactoring and continuous integration.
TDD is also a great first step towards adopting an Agile process
(particularly XP): it’s the thin end of the wedge, the sharp end of
the stick. I personally know several projects that are practicing
TDD to various degrees of rigor. Without exception they have
experienced dramatic increases in quality and significant overall
time savings.
My personal stand in the TDD camp is toward the “extreme” end:
tests should be grouped by fixture, not by any structural or lin-
guistic criteria; tests should be as simple as possible, ideally a
single assertion; tests should be refactored as ruthlessly as produc-
tion code; tests are written for design and specification, not for
verification; a developer should spend at least as much, if not
more, time writing tests as production code.
I am currently involved in raising the visibility of TDD in the
Smalltalk community (ironic isn’t it?) with my work on SUnit,
FIT, and various Mock Object related frameworks.
3. Kent Beck, kent@threeriversinstitute.org
Kent Beck is best defined in terms of relationships. Kent invented
and named Extreme Programming following work by Jim Coplien
and Ward Cunningham on software development process, with
Ron Jeffries and the C3 team at Chrysler - resulting in the Jolt
Productivity Award-winning Extreme Programming Explained:
Embrace Change. He is the co-author of Planning Extreme Pro-
gramming with Martin Fowler, with whom he also collaborated
on Refactoring: Improving the Design of Existing Systems. With
Ward Cunningham he wrote HotDraw, a widely copied drawing
editor framework, pioneered patterns for software development,
and popularized CRC cards. He channeled the Ancient Smalltalk
Masters to produce The Smalltalk Best Practice Patterns, and is
currently reviving a decades-old technique in Test-Driven Devel-
opment by Example (Addison Wesley). He lives on a southern
Oregon farm with a dwindling but still-impressive gaggle of chil-
dren, his lovely wife Cindee, four dogs, and a bunch of chickens.
Lean Production identifies two kinds of waste. The first kind of
waste is pure waste--you screwed up and you knew better, or you
are sitting around waiting because of poor resource allocation.
The second kind of waste is waste that is necessary at the moment,
but doesn’t really add value. Inspections are a perfect example--
your process creates too many defects to just ship units to custom-
ers, but you’d really rather eliminate the defects at the source, at
which point you can eliminate the inspections without removing
value.
The tests we write in TDD, then, are Type II waste--necessary at
the moment but not a direct addition of value. We need the tests to
write clean code that works, but the customer isn’t paying for the
tests, but the code. If we could figure out how to eliminate the
tests and still have clean code that works, we could improve pro-
ductivity substantially. How might it be possible to move from
Test-Driven Development to just Driven Development?
4. Barry Boehm, boehm@cse.usc.edu
Barry Boehm manages an annual ensemble of increasingly test-
driven software developments, and analyzes data on these and a
number of other commercial and government software develop-
ments. He is a professor at USC, and is the co-author with Rich-
ard Turner of a recent book comparing agile and plan-driven
methods, Balancing Agility and Discipline.
Test-driven development is a significant step forward from test-
last approaches. However, test-driven developers often find it
even easier to fall into several software testing pitfalls, such as:
• Testing to the stated (nominal-case) requirements. Data on
software rework distributions usually shows that the 20% of
the problems causing 80% of the rework are off-nominal re-
quirements.
• Value-neutral or risk-insensitive testing. Again, software
applications tend to have a Pareto 80-20 distribution in
which 20% of the requirements account for 80% of the busi-
ness value. Spending an equal amount of test effort on each
requirement is usually an inefficient allocation of resources.
• Overemphasizing testing or people-reviewing at the expense
of the other. Data indicates that each is much better than the
other at detecting some classes of defects, while some defects
are about equally addressable by both.
5. John McGregor, johnmc@cs.clemson.edu
I have had more than a quarter of a century experience with re-
search and trends of software design and development. I have
over a decade of substantial experience working on a wide variety
of systems developed using object-oriented techniques. This ex-
perience includes distributed, real time, embedded systems as well
as business information systems in a multi-tiered environment. I
have worked in various domains. These include telephony, finan-
cial, personnel, medical, scientific, aerospace, and the murky re-
gions of the legal domain and expert witness testimony. My roles
vary from an independent consultant mentoring corporate and
project management through an actual project team member as-
sisting with day-to-day tasks. I have assisted software develop-
ment organizations transition their projects as they adopted new
techniques such as product line development, object-oriented
development, and iterative, incremental development.
For TDD to be successful equal attention must be given to the
testing and design goals we hope to satisfy. Design is more than
just specification. Design coordinates interacting entities. Choos-
269
ing test cases that will adequately fill this role is difficult though
not impossible. It is true that a test case is an unambiguous re-
quirement, but is it the correct requirement? More robust design
techniques have validation methods that ensure the correctness,
completeness, and consistency of the design. How does this hap-
pen in TDD?
6. James Newkirk, jamesnew@microsoft.com
James Newkirk has been a software practitioner for over 19 years.
He has designed and implemented software in many different
environments, from real-time micro-controllers to large-scale
multi-tiered business systems. In addition he has managed groups
varying in size up to 40 software developers. He has been inti-
mately involved with the Agile Processes Community almost
since its inception. In 2001 he co-wrote Extreme Programming in
Practice with Robert C. Martin, published by Addison-Wesley.
The book is a pragmatic look at what it’s like to do an XP project.
He has also written many articles related to Extreme Programming
(XP) and Object-Oriented Design and spoken at conferences such
as XP/Agile Universe and OOPSLA. He is a major contributor to
the book Agile Software Development by Robert C. Martin,
which was published by Prentice-Hall in the fall of 2002. He is
currently writing Test-Driven Development with .NET with Alexei
Vorontsov, which will be published by Microsoft Press in the fall
of 2003. For the past 2 1/2 years he has been a frequent contribu-
tor to the development of NUnit, a unit testing tool for the .NET
environment. In early 2002 he became the administrator of this
open source project and led a small team that completely redes-
igned and implemented V2.0 of NUnit. The initial version of
NUnit was simply a transliteration of the Java unit testing tool
JUnit. V2.0 leverages more of the .NET platforms capabilities.
I believe that Test Driven Development works in practice because
it helps guide the design process from requirements into actual
running code. The act of writing a test starts the transformation.
The test represents an unambiguous requirement that the program
must satisfy. Since the rules state that you must satisfy this test in
order to proceed you have to focus on this single requirement.
This enables you as the programmer to shut off all the other re-
quirements and focus solely on satisfying this one. Once the test
runs successfully you can then take a step back, survey the land-
scape that was created, and touch up a few things (refactor) and
then move on to the next requirement. Often in other design ap-
proaches I have used the programmers gets paralyzed because the
problem that is being solved is so huge that it is difficult to know
where to begin. TDD recognizes the reality that you don’t solve
big problems with huge sweeping changes with little or no feed-
back. You solve a problem by making small incremental steps
which provide crucial real feedback. These small incremental
steps eventually lead to solving the large problem with a better
and more verifiable solution.
7. Charlie Poole, poole@pooleconsulting.com
Charlie Poole has worked in the software development field for
over 25 years, first in the IT department of a government agency
and subsequently as an independent developer, coach and con-
sultant. Charlie is a veteran C++ developer with a background in
the Windows SDK and COM. He has been working with the .Net
framework and C# language since the early beta releases and is
one of the developers of the NUnit open-source testing framework
 for .Net. He is the president of the Seattle XP Users Group and is overall design/metaphor of the project and the decisions one feels
active in promoting XP in the Northwest. the need to make right now. It’s a fact that this tension gets re-
solved, but the process by which it happens isn’t too well under-
TDD is one of the harder things for certain folks to grasp when it
stood and needs some clarification. The practice of routinely ex-
comes to understanding XP practices. On the one hand, we would
posing the cumulative result of all previously decisions to the
like to get people to use TDD from the beginning. On the other
team is what I call the “Big Story” practice: a translation of meta-
hand, insisting on it too firmly may prevent any movement toward
phor into something we can actually do, rather than something we
XP in certain environments. My current solution is to try to un-
simply have. By regularly telling the story of the application - the
derstand clearly what the client is asking for: if it tells me how to
result of many prior decisions - team members are helped to main-
do XP then TDD is central, but if it’s how can I improve my proc-
tain a common view - a theory, in Naur’s usage - of what the ap-
ess then TDD may come a bit later. Others approach this differ-
plication is about. The relation of this to TDD is that each small
ently and, of course, we all get to choose what kind of work we
decision is made against a common background which is shared
want to do. Aside from the tactics around adoption, the most in-
by the entire team. And when those emerging decisions turn out to
teresting part of TDD for me is its interaction with the overall
be not quite so small, the impact they will have on the overall
vision of the application held by the team at any given time. That
“Big Story” is known at the point of making the choice and can be
overall view is the cumulative result of many decisions,
quickly shared with the team in a form that’s easy to digest. The
some made up front but most emerging through TDD as the pro-
updated design/metaphor/story of the application forms the back-
ject progresses. At any given point, there is a tension between the
ground for the next decisions that must be made.

270

View publication stats