Test the Error Paths

Many people stop before testing the error handling of their software. Unfortunately, much of the perception of software quality is forged not by whether the software fails, because it eventually will, but by how it handles those failures. The world is full of unexpected occurrences. Even if your software runs on stand-alone, hardened computers, it will eventually fail. Power fluctuations, magnetic interference, and component failure are just a few of the many things that can happen, often in a cascading chain.

Error-handling verification ensures that your response to the deviant variations in your environment are deliberate rather than accidental. Deliberate error handling should give your user the experience you desire and hopefully the one they desire as well.

Many organizations skip or skimp on error-path testing because of the difficulties involved. Generally, inducing errors in larger scopes is harder than in smaller ones. Simulating network errors at a class level is much easier than for a full stack application. Making error handling an architectural concern with clearly defined guidelines for how components should participate in that framework outlines the intent to verify at the lower levels, allowing you to focus on the correctness of the local behaviors.