SOFTWARE

ENGINEERING
• Test-driven development (TDD) is a programming technique that
aims to provide clean, fault-free code (Beck 2003). TDD means that
first, HOT we write a test case that fails, and then we write the
simplest possible code that enables the test to pass successfully.
• TDD implies that new code is added only if an automated test has
failed. In addition, in order to improve our code, we perform
refactoring activities (Fowler 1999), in order, among other reasons, to
eliminate duplications.
• Accordingly, the TDD guideline is red/green/refactor, where red
means writing a simple test that fails; green means writing the
minimal and simplest code that causes the test to pass refactor
means that code quality is improved without adding functionality.
How Does TDD Help Overcome Some of the
Problems Inherent in Testing?

• TDD can help overcome some of the common problems associated

with traditional testing that are encountered in software projects.
Based on Dubinsky and Hazzan (2007), the following TDD analysis
addresses cognitive, social, affective, and managerial elements and is
structured around arguments frequently offered to explain why, in
many cases, traditional testing is skipped. Such arguments are
accompanied by explanations on how TDD might help overcome
these obstacles.
Not enough time to test
Traditionally, unit testing, if it exists, is performed after the code
is written and usually under time pressure. Thus, according to Van Vliet,
‘‘the testing activity often does not get the attention it deserves. By the
time the software has been written, we are often pressed for time,
which does not encourage thorough testing’’ (Van Vliet 2000, 397).
However, ‘‘postponing test activities for too long is one of the most
severe mistakes often made in software development projects. This
postponement makes testing a rather costly affair’’ (ibid.). Since TDD
introduces unit tests throughout the entire development process, this
problem is eliminated in TDD processes.
Testing provides negative feedback
• Traditional testing processes require the developer to find bugs in his
or her own work; in other words, testing activities end in failure.
Indeed, who would enjoy that?.
• In TDD, the rules of the game are reversed. TDD ends in success: after
the test fails, code is written and the test passes success To illustrate
HOT this perspective, we quote the reflection of a developer, Michael
Feathers ‘‘Why don’t people like testing?
• Well, the traditional way of testing is tough to take. You write what
seems to be perfectly sensible code, then you write a test and the test
tells you that you failed. No one wants to hear that. Let’s turn it
around. Write the test first; run it. Of course it fails
Responsibility for testing is transferred

• There are software development environments in which bugs

are found and, in many cases, also fixed by other practitioners
than the developer who actually wrote the code; thus, it is not
clear who is responsible for each specific testing activity.
• In TDD processes, the responsibility for testing is borne by the
person who writes the code.
Testing is a low-status job
• In some software development processes, testing is carried out at the
end of the production line, and, as with traditionally working class
jobs, the task is assigned low status, which in turn leads to tension
among different groups of employees.
• Cohen et al. (2004) reported that ‘‘though most organizations
recognize the need for high-quality testers and their specialized skill
set, testers still struggle to win the respect they deserve . . . .
• The lack of status and support makes the tester’s job more difficult
and time consuming, as the struggle for recognition becomes part of
the job itself’’
Testing is hard to manage
• From a managerial perspective, it is sometimes claimed that in
general, testing is a hard process to manage, and that in particular,
testing slows down the development process.
• Since TDD is firmly integrated throughout the entire software
development process, it turns development and testing into
controlled processes.
• Furthermore, the fact that TDD is done by writing automatic (not
manual) tests, further increases the control level. Indeed, introducing
TDD might slow down the development process in the short term
simply because testing is actually performed.
Testing is hard
• Testing is also difficult from a cognitive perspective mainly because it
is not always clear what tests are suitable for a specific purpose and
how much testing should be done.
• The following reflection of a practitioner, Ron Jeffries, explains how
TDD supports the testing from the cognitive perspective
• ‘‘A key aspect of this process: don’t try to implement two things at a
time, don’t try to fix two things at a time.
• When you get this right, development turns into a very pleasant cycle
of testing, seeing a simple thing to fix, fixing it, testing, getting
positive feedback all the way.
PROCESS QUALITY AND
PRODUCT QUALITY
PROCESS QUALITY
• Planning sessions are performed when all people involved in the
development process are present. Specifically, developers and testers,
system analysts and the customer, all participate together in the release
planning and the planning of each short iteration. This practice causes the
project subject and features to be known by all the people involved. Thus,
the project’s ongoing details are highly transparent. The impact of this high
transparency on quality is multifaceted.
• Among other things, we emphasize the high level communication which
significantly decreases misunderstandings and reveals problems before or
as soon as they occur. Another impact on quality is the adhering to
customer requirements, which are heard by all teammates. This kind of
transparency is highly appreciated by teammates and influences positively
their morale and the general atmosphere which, in turn, enhance a high
quality process.
• Process measures are available all the time to all the people
involved in the development process, including the customer. This
increases the transparency of all measures, e.g., the project’s
progress versus estimations, the customer satisfaction, etc. The
impact on the process quality of the measurement process itself,
as well as its ongoing availability to all the project stakeholders, is
clear.
• The one day the Business Day allocated every two weeks for the
presentation of the work accomplished in the previous iteration,
for reflective thinking, and for planning the next nine
development days, lays out a tight rhythm. This tightness
encourages a high quality process, since it controls the project
management, among other ways, by revealing and dealing with
unexpected events at early stages.
• The estimated work hours versus the actual time invested in the
development task is one measure by which iteration progress,
continuous integration, and release progress are measured (see
Chapter 5, Measures). This measure is tightly maintained by the
reports from each team member with respect to the time invested in
the development of each task (estimations are known from the
planning session). By letting everyone know the iteration progress and
the integration status on a daily basis, and the release progress on an
iteration basis, this measure increases the teammates’ awareness,
care, and attention to process quality issues.
PRODUCT QUALITY
• There is no one standard way to measure software product quality.
Besides different measurement approaches, several agile practices,
such as the ones presented in what follows, aim at constantly improving
the software quality.
• The goal of refactoring is to provide a simple and clear design which is
easy to maintain and simplifies future development extensions. By
performing ongoing refactoring activities, code is kept readable and
flexible. The refactoring activities include the examination of the code
and its design to find places for improvement, as well as the actual code
improvement and change.
• Such changes also include the necessary modifications in the unit tests
that support the code. These changes may be reflected in the code
measures that accompany the development.
• Pair programming enables code inspection for each piece of code.
This code inspection provides information in two levels of abstraction.
Such a multilevel examination increases the code quality since it
enables additional aspects of the code to be captured. Pair
programming also ensures adhering to coding standards as well as to
unit testing.
• The product quality is also increased by the definition of acceptance
tests that ensure the validation of each customer story. These
acceptance tests are defined by the teammates together with the
customer. During the definition process of the acceptance tests, the
customer stories are elaborated and become clearer and better
understood.
• The development process of the acceptance test itself increases the
teammates’ confidence with respect to the correctness of the
developed code and allows a smooth presentation of the software
functionality at the end of the iteration.
• Test driven development is a technique that enables a step-by-step
development of a specific functionality together with its unit test,
when each step of the test precedes the respective step of code.