Sponsored Link •
Bill Venners: You say in your book Refactoring: "If you want to refactor, the essential precondition is having solid tests." Does that mean if you don't have tests you shouldn't refactor?
Martin Fowler: You should think of it as walking a tightrope without a net. If you are good at walking a tightrope, and it's not that high up, then you might try it. But if you've never walked a tightrope before, and it's over Niagara Falls, you probably want a good net.
Bill Venners: What is the business case to add tests retroactively if you have no tests currently?
Martin Fowler: Again, you don't want to be surprised when the code breaks because somebody has changed it. 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.
Reliability is one story that hasn't been told about extreme programming (XP), which focuses heavily on testing. People talk a lot about its responsiveness and its light weight, but I hear more stories about XP's staggeringly high reliability. A couple weeks ago I chatted with Rich Garzaniti, an old colleague from the C3 project. The C3 project is often referred to as the birth project of XP at Chrysler where Kent first really put the various practices together coherently. Rich talked about this system he was developing using XP with testing and refactoring -- drinking the whole XP Kool-Aid completely through the system. He's had one bug so far this year.
Bill Venners: In Refactoring, you write: "I write tests to improve my productivity as a programmer." What about robustness, quality, and reliability?
Martin Fowler: They all come as part of the package. My view is that defects interfere with our productivity, because we have to take time to fix them. If I can eliminate a defect, I improve my productivity. The fact that I get more robust, reliable software is a valuable side effect. But fundamentally, I can program more features if I don't spend my time debugging and fixing bugs.
Bill Venners: So you invest the time writing tests that you expect to reap back by not fixing bugs.
Martin Fowler: I'll reap the time back within a day, because I spend so much less time debugging. I reap my costs back quickly on tests. Then of course all the other benefits come into play.
Bill Venners: Do you think that quick payback would result if a body of code has absolutely no tests?
Martin Fowler: It takes a longer time. I don't recommend you spend two months only writing tests. But I think you do benefit quickly by adding some tests, because you begin to find problems. If you focus your tests on the areas of the code you're changing, you'll find that when you make mistakes the tests will let you know about them. Obviously, you get the full benefit when you have a comprehensive set of tests, but even a few tests will start that process and begin to give you feedback.
Bill Venners: You said unit testing helps you be more productive, but you also say that one benefit you get from refactoring is the ability to program faster. How does refactoring help you program faster?
Martin Fowler: Because a better designed program is easier to change. The better the program design, the easier you can alter the program, and therefore, increase your productivity.