The average software engineer has a love/hate relationship when it comes to testing. Some people see its benefits wholeheartedly, and others just see it as an extra nuisance needed to get their PRs approved. Honestly, we’ve all probably been the latter at one point in our engineering journeys. However, it really takes one late-night production failure to scare any of us straight. Having to pull a random all-nighter because something failed will set anyone straight! That’s why for me, proper testing is the real hero of development.
Testing Is Insurance
For me, I compare the software development process to life. Think of a project you work on. It starts off as something small and insignificant, just like a baby, and grows into a full-fledged person. That would be the project hitting an official V1 production release. Now as a fully functioning adult, assuming of course you’re in a solid economic and geolocation, I would assume you’re not walking around without protection for your health. Health insurance, life insurance, dental insurance, etc. Something just to have in case something comes up so you’re well prepared.
In that same sense, that is exactly what testing is, insurance. Its purpose is to give you the reassurance that when whatever code you write is used in the real world, there are no cases where it crashes. That is because you should be writing multiple happy and unhappy test cases to the extent that it ensures your logic is as bulletproof as possible.
What Is Healthy Test Coverage
I lightly touched on this above, with happy and unhappy paths, and this is the pretty standard approach everyone takes. Unfortunately, even when those two are done solidly enough, most people tend to avoid one case from what I find. This being the absolute worse case, the crash/death case as I call it.
This is the case that covers the situation where everything fails, or something critical is needed to keep the application going. Testing covering this case is vital for good test coverage and ensures that your app can handle the inevitable ultimate fail case.
How Often Should They Run
Having test coverage in your app is only the first step in a long journey. The next step is deciding how often and where they should actually run. This can be articulated as your testing cadence.
Knowing where and how often to run your tests is another vital key in having a quality testing plan. In general, you’d want a healthy balance of ensuring new changes don’t break anything and whatever is in production stays healthy. For me, I always stick to a pretty reasonable approach: running test suites against open PRs relative to folder changes, all test run before merge into master/main branch, and scheduled tests running twice a day against staging and prod(when available).
In Closing
Testing is the one thing in software development that we can use as an insurance policy. It keeps us honest and allows us to sleep a bit more peacefully at night knowing we’re less likely to need to get up in the middle of the night. So if you have a bad perception about testing, just keep in mind, it’s meant to give you relief and not just add more work.