Agile Software Development:

A Briefly Introduction to Test-driven Development

Jason Carcamo Correa
Department of Systems Engineering
EAFIT University
Medellin,Colombia
jcarcam1@eafit.edu.co
March 17th 2014

Abstract TDD is one of the widely used agile software

development approaches within developers of diverse industries
and can be a challenge to newcomers.
Here is presented a recompilation of information, discussing the
general aspects, principles and misconceptions of Test-driven
development that in a way will help ease the understanding
of the concept and the use of it in any regular or complex
problem solving situation to TDD un-familiarized developers.
It is also included a simple example of the use of TDD on
a programming case problem in Java, that as easy as it can
be understood, it can be used to get the hang of test-first
development and the TDDs paradigm.

Keywords: TDD, agile software development, program

testing, software engineering, software development process
I. INTRODUCTION
In the software development field, sometimes is used a
bad perception to resolve and develop big software projects
under a specific software development model or rigorous
process like the waterfall model, that in a sense it enforces
discipline, it reduces risks and also provided more control
over planning, and how and where the project is heading.
But one of the foremost problem around this, is that clients
usually dont know what they want up-front, they tend to
know what they really want over time and when everything
they see is not what they imagine or explained, and where
making changes in an so advanced stage can delay even
more the development process and raise the costs of
everything, even having to do something from scratch.
Seventeen software developers in 2001 gather around to
construct what today is known as the Agile Manifesto
[1], that made an appearance after long years of debate
against the traditional software developing process which
bases stand-on thinking that software development was
like building a car, which is not. The Agile manifesto in
short terms refers to a more collaborative environment
between developers and business experts, face-to-face
communications, self-organizing teams, efficient written
documentation, high quality products and a vast emphasis
on frequent delivery of new deployable business value [1] .
Test-Driven Development or TDD, is one of the various
agile software approaches that combines test-first develop-

ment with refactoring to provide a better way to develop

high quality software that brawls the traditional development
process [2].
II. T EST-D RIVEN D EVELOPMENT
Test-driven development is a software development practice promoted by XP, which goal is to provide clean, faultfree code. TDD is just another word for Test-first development plus refactoring, where you first engage on writing a
test, you make it run and then you make it right [2] . On first
hand trying to understand the pure concept of TDD might
be a little difficult sometimes, as you introduce your mind
into a new paradigm were you told to code a test that fails,
as the first step to writing the solution of the test. In the
traditional development approach we choose a functionality
to implement, after everything is coded we test it and see
if anything fails, if and only if we find an error we modify
the code and test again until everything works. On the other
hand we have TDD approach were we write the tests first
instead of the production code, somewhat like reversing the
traditional process [4].
Let us try to imagine a process that you dont have a class
coded for it yet, and you are writing a test to make sure that
the process is working fine while taking for granted that the
class for that particular process exists, thats when you test
fails and you start creating the class and functionalities to
make the test pass.
A. In Simple Words
For TDD, you just have to pick a requirement, write a
test case that fails. Write the simplest code possible for the
test to pass successfully and then refactor without adding
any other functionality and after that, test again. If the test
passes again successfully then go and create another failing
test and repeat the cycle [3] . A thing to take in mind is that
this whole process is completed within minutes, not hours
nor days. So at any given time that you check the code, you
will have incrementally, simple working code. [see figure 1].
B. TDD principles
TDD has some rules that will help you understand easily
and corectly use this discipline, some of the common known
principles are [5]:

Fig. 1.

TDD cycle explanatory graphic

You are not allowed to write any production code unless

you are trying to make a test pass.
You are not allowed to write any more production code
that the one required to make the failing test pass.
Or even other more commonly referred words as KISS
(Keep it simple stupid), YAGNI (You arent gonna need it)
and some other principles with funny acronyms used in the
development world.

III. D EVELOPMENT Q UALITY

When we make use of the term software quality, we
are actually speaking of a non-accepted understanding of
what quality in terms of software really is, nor the common
software quality measures. The software quality standard
ISO 9000-3 states that There are currently no universally
accepted measures of software quality, but the supplier
of software products should collect and act on quantitative
measures of the quality of these software products [2].
A wide community of developers have experienced the
use of TDD in various projects and comments of their
results are that TDD provides high-quality code [6], in these
cases quality referring to clean and understandable code
that includes fewer bugs than those developed under the
traditional methodologies. This simplified outset of some of
the quality measure given to software products, they found
that developers after being distressed throughout changing
how they used to code, the results of using TDD have made
some improvements and benefits in the long run [2,3] .

Not having enough time to test: Usually when a developing solution via the traditional testing, things are
entirely focused on code that will make all work as
fast as possible, not wondering if youre making a
mistake with every new piece of code added, and
just until everything is finished, we start testing the
product with little time left to the deadline and probably
under pressure. TDD breaks in, introducing unit tests
throughout the developing process making this problem
go away [1].
Testers In some software companies are hired to find
and fix, if necessary, bugs on a software foreign software that with some fixes here and there some other
errors may emerge not knowing who was the actual
responsible for them [1]. TDD does not transfer responsibility issues over code, instead is carried by the person
that actually writes the code.
Slow development do to the fact that testing is hard to
manage, therefore it will slow the development process
down [1] . On the other hand, introducing TDD might
slow down the development process in the short term
simply because testing is actually performed. In the
long run, however, it assists in shortening the integration
period [1], especially if there are continuous integration
throughout the project development.
V. M ISCONCEPTIONS

TDD is a concept that is widely used by developers but

sometimes the real meaning gets mixed and means something
different to a bunch of people, thats one of the reason
to find different information or practices in the software
development industry. When making a reference to TDD,
some people say they use TDD but they are really talking
about that they use test-Oriented development [5], meaning
that they do a lot of tests that not necessarily write before
the code. Others say that indeed they dont use test-driven
development, they say they use test-driven design, a process
that involves not only writing test before the code, but also
writing tests without having a basis of a design whatsoever
[5]. On the contrary Test-driven development means exactly
that, is driven by tests, so you need to write the test first
before writing the production code [5].
VI. A S S IMPLE A S I T G ETS (I N JAVA )
Here is an example of the use of TDD. Dont focus on
the simplicity in the following example, or how useful would
be when implemented on complex systems, but it can help
illustrate on smooth terms the use of test-driven development
in a common widely known programming language such as
Java.
A. fix my typo, please.

IV. OVERCOMING S OME P ROBLEMS

The process of traditional testing have some flaws that
are encountered in software projects [1], by explaining how
TDD can help with some of the most common problems can
come as a good argument to switch to TDD, for instance:

If someone is trying to write the word correction, and

by mistake they typed correctino by the time they hit the
keyboard key space our little method should autocorrect that
mistake to save time and help the writer continue his work
without having to care for a finger slip mistake. One of

possible things we could do is create a method that can

handle a character swap in case that the problem detected
is on the last two characters like in the example word.
Lets start by creating a simple JUnit Test class that is
going to be called StringSwapTest, this class will contain
the following simple structure:
P u b l i c void StringSwapTest {
@Test
P u b l i c void t e s t ( ) {
F a i l ( Not Yet I m p l e m e n t e d ) ;
}
}
When we run this code the result is that it fails, we are
not sure what problem we are going to have to solve, so
lets make this test more specific by adding the necessary
information for it.
public class StringSwapTest {
@Test
public void
testStringWithLastTwoCharsSwap (){
StringSwap c o r r e c t o r =
new S t r i n g S w a p ( ) ;
a s s e r t E q u a l s ( no ,
c o r r e c t o r . swapLastTwoChars ( on ) ) ;
}
}
public c l a s s StringSwap {
public String
swapLastTwoChars ( S t r i n g word ) {
return null ;
}
}
The StringSwap, is the actual class that will contain the
method to resolve the issue, preferably created on a different
package than the one holding the tests, and also adding a
JUnit test called assertEquals [7], which the test will pass if
no is equals to the result returned by swapLastTwoChars
with the on as the given input parameter string. If we run
this test we get as a result that it fails, which turns out to
be a failing test just like we wanted by following the TDD
steps. The next step will be to code as little as possible to
make this test pass, any simple solution can work, perhaps
like this one:
c l a s s StringSwap {
public String
swapLastTwoChars ( S t r i n g word ) {
char f i r s t C h a r = word . c h a r A t ( 0 ) ;
char s e c C h a r = word . c h a r A t ( 1 ) ;
return + secChar + f i r s t C h a r ;
/ / reversing chars
}
}

When we run again the test we see that now the test passes
the evaluation, we reached the second step of TDD. And now
comes the refactoring step, in this example probably there is
something to be refactor, but assuming that there is not more
possible refactoring to do, we finished the test, meaning that
is working at first hand but this code does not resolve all of
our problems, so at this point is where we start again with
the cycle of TDD making another test for our little program.
Perhaps coding another test for the same method, but this
time adding a more complex input such as the full word or a
test for fixing a word whose error does not lie on the last two
characters but do in the middle area. And many more test
that we can think of to help cover a wide range of common
and uncommon errors that by having control over them, we
could provide a good quality final product.
R EFERENCES
[1] Orit Hazzan, and Yael Dubinsky, Agile Software Engineering.
Springer, 2009, pp. 1-14, 121-128.
[2] Lech Madeyski, Test-Driven Development: An Empirical Evaluation
of Agile Practice. Springer, 2010, pp. 1-3.
[3] Vesa Lappalainen, Jonne ltkonen, Sami Kollanus and Ville Lsomttnen,
ComTest: A Tool to impart TDD and Unit Testing to Introductory
Level Programming. 2010.
[4] Sohel Rana, Test Driven Development (TDD) Step by Step. 2009.
In:
http://www.codeproject.com/Articles/47747/
Test-Driven-Development-TDD-Step-by-Step-Part-In.
Visited in March 2014.
[5] Roy Osherove, the art of UNIT TESTING with Examples in .NET.
1st Edition. Manning Publications, 2009. pp 1-20.
[6] Steven Fraser (Chair), Barry Boehm, Dave Astels, John McGregor,
James Newkirk, Kent Beck and Charlie Poole, Discipline and Practices
of TDD (Test Driven Development). 2003.
[7] Java test Primitives, AssertEquals(). IBM Infocenter.