An XP project is always in maintenance. We deliver to end-users, early and
often, so we expect that most of development (the RUP "inflation phase" and
"implementation phase";) is changing code that users must expect to be
stable. All the tests, together, support maintainability. The onsite
customer remains aware of real customer's workflow, and helps not derail it.
To get this, you research known security issues and their fixes, your team
votes on which ones your project needs, and you implement them using TDD.
You don't expect a secure system to emerge via TDD for all the other
features. There are always ways to crack systems, even bug-free ones.
The C++ literature, for example, talks too much about portability, because
some C++ developers have the goal of matching their application to any
platform that supports C++. This leads to too much newbie traffic on
nobody needs. This has lead to the admonition:
==> portability is for canoes <==
However, XP supports portability better than C++. XP programmers generally
agree that if you port between platforms, or migrate between languages or
systems, that you throw the code away and keep all the tests.
However, if your code must simultaneously support several back-ends (such as
GameCube, XBox, PS2, etc.), then you need portability in space, not in time.
In this situation, you must run all tests on all platforms at integration
time. This requires a Test Server From Hell, to manage all the permutations
of ramifications of all platforms, and synchronize their testage in
lockstep. This aspect of test servers needs further investigation.
The effect of refactoring code, under test, simply cannot be understated
here. Some traditional testing techniques rotate test criteria thru many
permutations, and run them all against the same code. (If you need that kind
of testing, you should add it on top of the XP testage.)
XP's refactoring practice rotates the same tests thru steadily contracting
permutations of code. As duplication squeezes out of code, and as its
continuously reviewed and cleaned, there are simply no places for bugs to
If you say, "Ah, but what about 100% availability". That's a feature, and
the onsite customer must request it. The reason it's a feature, not an
emergent property of clean code, is very simple. No matter how tested your
code, life, and karma is, somewhere out in space there is a cosmic ray with
your CPU's serial number written on it. If you need availability, you buy
it, typically using common techniques like redundant servers.
So, in conclusion, the answer to everything is "tests", and the answer to
"tests" are all the other XP practices that support tests.