The value of unit testing.

Last week, Raymond Lewallen posted a refactoring pattern quiz. A lot people view refactoring as a "bad thing" since you're taking existing, debugged (sometimes in-production) code and changing it. While there is definitely the riesk of introducing regression bugs, Raymond addressed an important point in deflecting some of that risk:

...you will ALWAYS want to write a unit test for your initial code and make sure it passes all scenarios BEFORE beginning your refactoring process and DURING and AFTER your refactoring process.
Unit tests can not reduce the risk of regression bugs to zero, but with a good set of unit tests, the risk can come very close to zero. That's another reason to start writing unit tests NOW. You'll learn more about the process of unit testing and over time you'll be able to write better and better unit tests.
Published Sunday, May 1, 2005 12:20 PM by PSteele

Comments

# re: The value of unit testing.

Interesting. The thing about unit tests is they will of course pass because you are checking for the expected. The thing I notice about refactoring is something that used to work fine inevitably has some sort of production issue (fails undr load etc.). There is a risk with refactoring no matter how good you think your unit test is that unit tests will fail to catch. Any refactoring should trigger a full regression test.

Sunday, May 1, 2005 12:40 PM by Dave

# re: The value of unit testing.

Dave, therein lies the advantage of test driven development and red-green-refactor. When you write the unit tests first, you're tests will of course fail, so you can only write the minimal amount of code that is required in order for the unit test to pass. Of course, this isn't always the case and you will have to write unit tests to pass after you've written the code. I disagree with you on almost everything you said. Refactoring does not lead to an inevitable issue (fails under load would be one of the least likely scenarios) on a production server. Especially since you say (another thing I disagree with) is that any refactoring should trigger a full regression test. If you're doing a full regression test and you inevitably have production issues with your code, there are obvious failures in your processes that refactoring and unit testing have no or little part of. If you run the unit tests to check for passing each time you change code, you've given yourself a much better piece of mind and guarantee of a successful refactoring than most regression testing will every produce, especially on large systems. I do agree that refactoring does produce risk, but I disagree with you that you will always leave something out that unit testing will fail to catch and there will be an inevitable problem with your refactoring because you didn't write good enough unit tests. If you've spent a good amount of time writing unit tests and are familiar with the business process that the piece of code abstracts, you most likely are producing valuable and valid unit tests and ensure that the refactoring process causes no failures in code. Naturally, there are no guarantees, but the guarantee of success is a much higher percentage than one would be led to believe from your comments.

Sunday, May 1, 2005 2:14 PM by Raymond Lewallen