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
legacy code
If you’re having trouble testing legacy code, mock a logger
I was working on some legacy code (“legacy” meaning it has no automated test coverage) and I really wanted to write some automated acceptance tests for it. The problem is, I could not think of a way to do that without refactoring the code first. I did not want to do this because “it was already working” and the refactoring could have introduced new bugs. I had a chicken and egg problem: I didn’t want to modify code until I had automated tests but I had to modify code to write the automated tests. Which comes first?
I ended up using a trick that minimally changes the production code, actually improves the production code base, and allows me to write automated tests. It’s these two simple steps:
For legacy systems, I really wish Java had monkey patching
A big part of my job is maintaining old code bases. Unfortunately, it’s rare that these code bases were written with testability in mind. As a result, I start with very little confidence in the changes I’m making: I’m not sure how the code works so I can’t safely say that my change are safe. In my opinion, the best way to gain confidence in a code base is to write automated tests for it. But usually easier said than done.
Here’s a problem I always have to deal with: I can write a bunch of automated tests for the legacy system but the tests will eventually access a database or call a remote API that is super slow. Before I know it, my tests take 10+ minutes to run. Once that happens, I run them less frequently because the wait is a pain, and when that happens, it takes me longer to notice if I’ve introduced a bug.