Datasheet

9
Chapter 1: Preliminary Concerns
paradigm happens with software development. Project managers spend a great deal of time working
with customers to define exactly what a piece of software should accomplish. However, it’s common to
find that after the project manager has completed collecting the requirements for an application, the cus-
tomer doesn’t see the application again until development is “finished.” This is the reason many software
projects fail. In the last few years, Agile Software Development processes have became very popular
among developers. One of the key principles in Agile Software processes is iterative development.
Iterative development groups the development of new features together and delivers small chunks of a
project to a client, rather than waiting a long time to deliver a very large monolithic system. Agile teams
try to keep the iteration period low, perhaps two weeks to a month, and at the end of the iteration they
always have something to show. Some attribute the success of Agile to short iterations and constant
communication with clients.
Agile developers and managers often speak about reducing the cost of change. Cost of change simply
put is this: the longer it takes you to find a defect the more expensive it will be to fix. The cost of change
topic is discussed heavily in the project management world; some attribute low cost of change to a very
close feedback loop with customers, managers, and developers.
Testing suites can provide many entry points for gaining different types of feedback. At a very low
level, testing provides feedback from the code itself about its current state and whether or not it is work-
ing correctly. At higher levels, acceptance testing gives developers feedback if the system was devel-
oped to specification.
Why Should I Learn about Testing?
You’re reading a book about testing for the web, so you’re heading in the correct direction.
For Developers
Developers tend to be busy people, what with new technology trends emerging and customers con-
stantly demanding new features. At times, developing software is a very stressful profession. Worrying
if the new feature you added this morning is going to break existing functionality should not be some-
thing developers are spending time thinking about. Having a test suite that spans from unit tests to
customer acceptance tests will help a developer sleep better at night, at peace in the knowledge that the
software is functioning as designed.
A well-written test suite will provide the proverbial safety net. With this safety net in place developers
are more willing to refactor (changing the internal structure of how code works without modifying its
external behavior or functionality) sections of code, experiment more often when getting ready to add
more functionality into a system, and be more Agile. The end result is an improved code base and
fewer areas within your code base that you are scared to make changes to.
One aspect of unit testing that new developers to automated testing often overlook is the fact that testable
code in most circumstances is also well-designed code. Design patterns such as Inversion of Control (IoC),
and simple development concepts such as Don’t Repeat Yourself (DRY), together with a strict separation
of concerns are needed to create testable code (concepts that will be discussed thoroughly in Chapter 2).
96640c01.indd 9 9/25/09 7:18:28 AM