Testing isn’t always a glamorous endeavor. It’s akin to confirming someone else’s scientific results: needed, and not noteworthy. But I would argue that in fact, testing can be as important as the code we write.
Testing serves as a great way to get a good view of the overall health of your application. It is not the magic solution to any issue, but is instead a tool used to find and fix weak code. With proper testing in place, you can confidently update your application and add features.
I like to think of my testing suite as my blueprints for my house. They alone are not the end-all answer, but often they give me vital information. If the drywall guy tries to cover over a doorway (first hire someone else), I would know from my blueprints that this should be a doorway, not a wall. If I have a leak in my hallway, I may not know what pipes may be behind this wall. The hallway is connected to the living room and the dining room. No water should be in this area. But with my blueprints, I would be able to tell that the pipes for the guest bathroom upstairs run through that specific section of the hallway. The issue may be with the guest bathroom, but without a good knowledge of the overall plan and purpose, I may have started down the wrong path of thinking the water was coming up from below. I could waste valuable time, energy, and money fixing the wrong issue, just to have to pay to fix the actual issue later.
Test suites act in much the same way. You may get a series of errors that individually look like a bunch of one-off problems, but in reality are a cascade of failures caused by a completely separate issue. Being able to run an automated test suite means any developer on our projects can diagnose and mitigate any issues that arise, not just the creator. A strong test suite allows us write the code to patch vulnerabilities in a matter of hours, not months.
You might be tempted to think “That’s all well and good, but I can draw up those plans later.”
But can you? Really?
Going back to the house analogy, if you tried to draw up the plans afterward for the building, would you remember to include the THREE wires from the dining room outlets? Or the fact that you changed from 24” stud spans to 18” for this specific reason in this one specific wall? How about the specific color of the paint along with the brand and where to purchase more if needed?
Testing can also act as a guide for your code. TDD (test driven development) allows the programmer to keep the code in line with their intention, while also ensuring nothing else was accidentally changed in the process.
It’s risky to take the “fill it in later” approach to testing. Too many things can be forgotten or overlooked. It’s very easy to overlook an aspect of a feature, forget to test sad path edge cases, or even forget to test an entire section of your code. Applications get big and complicated quickly, and your testing will be most effective if it follows all the crazy twists and turns your code makes as it makes it.
If you are already deep in a project, add the tests! Testing after the fact is still far superior to no testing. Just understand that you are trying to do a word find with no idea of how many words are hidden in the puzzle. Some tests will be easy to write, but the further you get, the harder it may be to find all the edge cases and testing scenarios needed.
Testing allows you to be a better coder now by ensuring the code does what you expect in multiple scenarios.
Testing allows you to be a better coder later when you don’t remember all the intricacies of the app, but you now need to add a feature.
Testing allows you to be thought of fondly by the developer who will carry on your work when you move on in your career.
Testing allows your hard earned contributions to the tech community to live on as robust, quality code.