Testing Is Insurance

Nobody Likes Insurance

The reality of life is that people dislike insurance. We dislike buying, paying for, and dealing with all types of insurance because it’s something we hope we never use. However, all of us accept the fact that insurance is required in the modern world for a variety of reasons. Indeed, the very thought of going a day without insurance can be stressful. In certain cases, it is a life-saver.

Testing in software is no different. Developers (Including myself), dislike writing and dealing with tests. But deep down, tests are no different than insurance or security. We must accept the reality that-just as with home or car insurance-tests are a necessity in software development.

Software requires good testing:

  • Insurance is paying now for issues that may or may not happen in the future. In software, however, issues will happen. This is a guarantee.
  • The more an asset depreciates in value, the less you need to spend on insurance. But, in software, testing is an up front cost that is paid when setting up infrastructure and getting developers accustomed. As the project matures, the costs of testing will naturally subside.
  • The more expertise you have with an asset or subject in the real world, the more understanding you have in regards to the level of protection needed. Likewise, in software, developers become more accustomed to the creative process and improve their ability to write tests; This reduces costs over time.

Your Tests Are Your Insurance

As a software engineer, when you write a test-(whether it be a unit, integration, or end-to-end),-you are investing in your application's future. Your time and effort will pay dividends later when someone needs to modify the software.

  • Tests allow us to refactor at will and provide the confidence that behavior will remain the same
  • Tests describe behavior to other developers, acting as another form of documentation
  • Tests allow us to automate things in ways manual QA can not

A failure to implement automated testing in any project is taking a major risk. It is akin to skimping on insurance and merely hoping that nothing terrible will happen. This is not a sound policy for developers.

Tests may be as frustrating to write and maintain as it is to pay care or home insurance, but tests always pay the bill in an application's lifecycle. The larger and older the application gets, the more testing pays for itself. Once a developer understands and appreciates the benefits and buffers that automated testing provides, the time investment required to test ultimately ceases to be a concern. In the end, an ounce of prevention is worth far more than a pound of cure.