Gratuitous complications: unit test fault injection

Spread the love

Sometimes things don’t need to be complicated. I would go so far to say most of the time things don’t need to be complicated. In the words of Uncle Bob Martin, “it is the software engineer’s job to make tough problems easy to solve.” Here is a quick example of a gratuitous complication I see often enough to warrant a cautionary post.

In a previous post I discussed fault injection, specifically of the black box kind. Given how useful fault injection can be in getting holistic testing of error handling paths, it seems natural to want to make this practice ubiquitous. Indeed you’ll see many links on the web about applying fault injection tools and libraries to what would ostensibly be unit tests.

Presuming you already have unit tests and a relatively testable design, you are already 90% of way to having a fast and reliable mechanism for deterministic fault injection. It is called… programming a test double to throw an exception and then verifying the exception is handled correctly. (The lack of a catchy name does make marketing this approach harder, but don’t be dissuaded.) By all means, continue to use heavier fault injection machinery to find gaps in your design — consider these tools like the spackling paste to the cracks in your software walls. Just don’t paint your whole house with them.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.