If a code base is well tested and very stable, it’s pretty easy to write more tests for it. But, how do you get started writing automated tests if your legacy application has none? It’s very difficult to get started because the code wasn’t written with tests in mind. Normally, the endeavor will have you pulling your hair out. This is unfortunate because a lot of untested code desperately needs tests, yet it takes an inordinate amount of effort to write them. In this article, I’m going to tell you about a tool that you probably haven’t heard of that can help you get that legacy code base tested. It’s called Approval Tests, and here’s how it works: Continue reading
approval tests
You should not be afraid to change code
If you ever work on code and are afraid to change a part of it because it might break, you’ve got a serious problem on your hands. If you are afraid to change code, that means you’re afraid to improve code. That means you can’t make it better and you can’t add features to it. Living in fear is no way to live.
If someone ever says, “don’t touch it” in regards to code, that means someone screwed up a long time ago and now everyone at the company has to pay the price. The code is holding your productivity hostage. There are so many ways you’d like to improve the code in your project, but your changes keep on getting tangled up with this knot of instability.
This is not the natural order of things. Just because a project lives long enough doesn’t mean that there has to be fragile pieces of code that break if you look at it wrong. It’s just that so much technical debt has added up around the code that someone should have dealt with it a long time ago. Now, nobody wants to deal with it. If you or your company is afraid to change a piece of code, “you’re doing it wrong”. Here’s how you can fix this problem: