
fter the
e-Commerce SIG
talk I started chatting with a fellow attendee. We talked about what was not
covered by the presentation.
The conversation drifted toward
Test Driven Development (TDD) —and for good reason. To my mind, there are so many benefits that it’s
hard to pick a single winner.
But TDD isn’t for everyone. If writing tests
before writing code feels too
extreme, or if you’re working with
legacy code that has no tests at all, don’t let the
ideal of test-first
stop you from writing
any unit tests. Start where
you can. Something is always better than nothing.
Here are just a few of the benefits of writing
unit tests:
Confidence Through a Safety Net
Unit tests give you the confidence to make changes, knowing that regressions
will be caught early.
Pressure to Break Dependencies
When a module is hard to test, that’s often a clue (a code smell): it has
too many dependencies. Testing encourages better separation of concerns.
Better Object-Oriented Design
Poorly designed code is hard to test. Unit tests push you toward cleaner,
more modular, and more cohesive components.
External View of Your Component
Writing tests helps you see your code from the
caller’s perspective—which naturally leads to more intuitive APIs and usage patterns.
Now, ramp that up with
TDD—writing the test first—and you get all of the above, plus some added
magic:
Focus on What, Not
How
Starting with a test forces you to clarify
what you’re trying to
achieve, instead of diving straight into implementation details.
Discover Code That Already Works
Sometimes you write a test… and it already passes. Why? Because the system
already has that behavior.
This has led me to delete large sections of legacy code that
were—frankly—doing nothing useful.

(It’s both satisfying and depressing.)
TDD discourages speculative code. You implement
only what the test demands—not what you think might be needed
someday.
.