Testing legacy apps
businesses adapt
A business that stands the test of time is probably a business that is good at adapting to change. They embrace new technologies, they test new ideas, and they jump when they see an opportunity in the market. These changes do not go unnoticed to those building and maintaining the technology that runs the business.
technology follows
If your business is changing, then there’s a good chance that your technology requirements are too. As product designers and developers, you’ve been there when someone says that they’re taking a hard left turn away from that feature you shipped last quarter. Now they need to solve a different problem that your feature isn’t adequate to solve. Maybe it just needs to change a little bit, how bad could the change be?
why software changes
We build products knowing they will change (or they will die). The software will change to build that new feature, to fix a bug, or to tune that algorithm so that the head of marketing gets all of those juicy marketing numbers every morning. There’s also the recurring intrest payment on the tech debt you’ve been accumulating, or the all-hands-on-deck debt payoff when the pressure of that technical debt becomes insurmountable. Whatever the reason for change, change is inevitable in the modern workplace. Don’t avoid it, embrace it.
legacy software
So you’ve landed an exciting role at a big company with all of the perks you could dream of. Your first assignment is to fix a bug in their mission critical weekly financial summary report. You get access to the code base only to find a single source directory and a few test data files. You follow the setup instructions and figure out how to fire up the development environment with ease. Then the cold sweat breaks out as you wonder, “How can I reproduce this bug? How will I know that I’ve fixed it? How will I know that I’m not going to break something when I fix this bug?”
testing
If you’re looking at a system with zero tests, then the first thing you could do is to write a few integration test scripts that describe how to manually test the system. At a minimum you will understand the required inputs and expected outputs. You will also have reproducible steps to get from those inputs to that output, including steps to set up the test, how to run the test, and how to assert that the output meets expectations.
automation
This tediously manual process probably won’t last long. You’ll be looking for ways to automate as much of this as you can. Hopefully you’re working in a language that has good testing frameworks that you’re confortable hooking the application into. It might not be easy, but you’ll find ways to test the “untestable” code. You can find out great techniques in the book Working Effectively With Legacy Code authored by Michael C. Feathers (Prentice Hall).