| « The conference talk creation process | Do your objects talk to strangers? » |
Green field projects are certainly rare, but they hold a certain appeal over developers. The ability to ignore all the mistakes of the past, and instead focus on new architecture, new ideas and new methodologies is enticing. And yet, every pile of legacy code spaghetti out there was once a green field project, filled with the majestic hopes and dreams of the engineers who worked on it. What happens?
I know many developers who believe that code simply gets worse over time, that technical debt accumulations are inevitable and that bad decisions haunt us forever. But the truth is that code doesn’t rust. And that means that our ability to make changes is directly related to how well we create the code in the first place.
The problem is actually a direct result of our decisions, and one particular decision rises above the others as the main culprit in making applications harder to change over time. That decision is the decision not to develop an automated test suite.
Much has been written on the virtues of testing: it reduces the bugs in your code, it helps you go home on time every night, it helps you to refactor. But the biggest advantage of an automated test suite is its ability to help you add new things to the code and have confidence the old things still work.
For example imagine that you’re adding a checkbox to a form in a user’s profile. How do you know that the presence or absence of that checkbox won’t cause problems elsewhere? How do you know that removing a checkbox won’t have adverse consequences? Without tests you have to test every part of the application. For anything more complicated, you end up with absolute paralysis. Making changes is impossible.
This makes unit testing (or the lack thereof) a business problem. Any application will eventually grow to a sufficient size that without an automated test suite, it will be impossible to modify.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 2/3/2015 at 9:48 am
Peter Drinnan wrote at 2/8/2015 8:48 pm:
I’ve seen the cost of having no tests first hand. On legacy projects every time we do a bug fix, we have to have people manually test everything before we go live. Going forward we are writing tests prior to any new code, but we’ve got miles to go with the old stuff.
I don’t thin it can be stressed enough. Not having tests costs real money in the real world.
Thanks for the article.
Pete
Josh Adams wrote at 3/11/2015 1:04 pm:
Not sure I should admit this, but that picture is the only reason I clicked through to this blog post (LOL) but I’m glad I gave it a read anyway – proper testing most definitely saves time and money.
Good stuff, Brandon.
| « The conference talk creation process | Do your objects talk to strangers? » |