The world of software development is constantly evolving. New tools, techniques, and technologies are being introduced every day, and it can be challenging to keep up with the latest trends.
However, there are some issues that never seem to go away, no matter how much progress we make: legacy code.
Can I get a high-five if you’ve ever dealt with legacy code?
Legacy code is something we’ve all had to had to deal with at one time or another. The code may be poorly documented, contain chunks of commented-out code, or have no comments at all. Often, there are few automated tests, making it challenging to know if the code is working as intended.
So, what do you do when you find yourself in this situation?
Easy: Start testing.
What??! That’s your whole thing? “Start testing?”
Let me clarify. It’s easy WHAT you must do and that’s to start testing. Before you alter any features, if possible, if you can hold off the minions of management and community and before you “fix” a single thing and first write a test case, that would be perfect. (I understand if you can’t.)
But deciding to “start testing” will not be easy to CARRY OUT. Believe me, I know.
In fact, it will be very VERY hard. So continue reading if you want to some tips that at least give you a decent shot and moving that boulder up the hill.
To start off, don’t get caught up in the purity of total isolation or worry about obscure test methods. Just start writing tests. It doesn’t matter if you use the right name or if you’re writing a unit test, a thread test, or an integration test. What matters is that you’re writing a test.
For example, consider a system I once dealt with that parsed electronic invoices and stored the parsed results in a database. The parsed results weren’t handed back through any API, so I had to write a test that checked the results in the database.
Yes, that’s ugly as all get out. It’s often un-recommended.
And sometimes…it’s EXACTLY what you must do.
- I started my test case by programmatically emptying all the tables relevant…