Your mileage may vary for all sorts of reasons. Some programmers take to TDD like ducks to water, others don't (for more on
this idea, see our exclusive interview with Brian Marick , founder of Testing Foundations). Some projects support more fluid business environments than others and must evolve not
only during development but also while in use.
If outsourcing is part of your development strategy, it's incredibly useful to know that your software can be modified safely
by new teams. When we interviewed Glen Snyder, vice president of engineering at Natick, Mass.-based edocs, for "Leveraging a Global Advantage," he stressed the value of a testing safety net.
"A developer working here in Natick can easily modify code written by a guy in Sri Lanka," Snyder says. "We build every hour
against our tests, and when somebody needs to make a change, they trust the tests to tell them if they did something bad."
Developers increasingly rely on components, and now Web services, created by other developers. Here TDD can have a dual benefit.
Writing a quick series of tests to exercise some unknown code is a great way to learn what the code really does, as opposed
to what it's documented to do. The resulting tests can then be used to assure that, as the component or service evolves, it
continues to behave in the expected ways.
It doesn't cost much to try TDD on a modest scale. The xUnit tools are freely available for many programming languages (see
Unit testing for Java and .Net made simple). Individual developers within your organization can choose to start using them and, quite probably, some already are. But
TDD doesn't replace stress, load, usability, and acceptance testing. So if TDD takes hold, you'll want to consider how to
integrate it with these conventional techniques. Cunningham's FIT (Framework for Integrated Test) is one such effort; it aims
to connect business analysts and their acceptance tests to the TDD process.
TDD may also reveal new uses for conventional testing tools. Deborah Kablotsky, director of product management and customer
support at RadView Software in Burlington, Mass., notes that although her company's products focus on load testing, their
underlying engine is a general-purpose scriptable emulator. "It can instantiate Java classes and exercise things on a component
level," she says, "and it can emulate communication protocols like HTTP or JDBC." Here's how TDD could mesh with that technology:
To practice TDD effectively, tests have to be quick and easy to write. But setting up a complex environment -- with databases
and networks in predictable configurations -- is arduous. Conventional testing tools that specialize in simulating real-world
conditions could help lower TDD's activation threshold.
TDD doesn't claim to be a silver bullet. It's just a simple, common-sense approach to doing what programmers have always known
they should do: Test early and often. Nobody would argue that you shouldn't adopt these good habits. The question is how to
sustain them. For a growing number of software professionals, the combination of xUnit tools and test-first methods are proving
to be a good answer.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
