The Perils of Software Regression
Understand the risks of software regression, how code changes can unexpectedly break functionality, and why regression testing is crucial. Learn to identify causes such as feature additions, bug fixes, refactoring, and optimization, and grasp how unit testing with frameworks like NUnit can prevent hidden bugs in complex projects.
Introduction
In his book, Working Effectively with Legacy Code, Michael Feathers says “The adage, if it ain’t broke, don’t fix it doesn’t necessarily apply in the case of technology. Projects continually require alterations, updates, and enhancements.”
Whenever a change is made in code, it may break existing functionality. If these changes result in breaking existing functionality or in degrading the quality of the code, the code undergoes software regression. Software regression is a type of software bug where a feature that has worked before stops working. These bugs happen through changing existing code and typically, the developer misses these bugs.
Code change rationale
If there is a probability that software regression occurs after a change is made, the natural question then is: why change the software? In reality, software always changes, even software that has reached a very high level of maturity. This concept is illustrated below:
The rationale driving software change may be classified into the following four categories:
- Feature additions
- Bus resolution
- Refactoring
- Optimization
Feature additions
Feature addition is seen as the most frequent rationale for changing software. In essence, the change is brought about by the addition of features that typically increase the size of the codebase. A feature addition is a code change that adds a ...