Safe refactoring
I don't know where I'd be without my tests. I've become so dependent on running JUnit tests that I just can't imagine fiddling with code without seeing the stress-reducing green bar. Writing tests before the code that makes them pass has helped take my design skills to a whole new level. I considered myself to be a darned good OO designer, but I'm finding that simpler designs emerge from testable code. More importantly, I get early and often feedback that the designs actually work. As a second order effect, the code tends to have a lower defect density.
That's all good, but there's more. I continue to be pleasantly surprised by how "testing" actually makes programming more fun. Being able to aggressively add new features and refactor without fearing that something will break has had the biggest influence on my productivity over the last 2 years. That's right, all the whiz-bang tools and technologies I've learned in that time don't hold a candle to the power of this programming technique.
Bill Venners recently posted his interview with Martin Fowler on the virtues of refactoring and testing. Martin says:
One great thing JUnit-style tests give you is the ability to run them and see if you've broken anything. It's no big deal if you aren't changing anything, but if you're adding features or fixing bugs there's always the chance you'll break something. As you get better at your tests, you become more confident about the things you can change. As a result, you can get some high reliability rates.
I heartily recommend reading the refactoring interview, then topping it off by reading Part 2: Design Principles and Code Ownership. Timeless stuff!