This is a question that brings out very strong beliefs on either side. On one side of the room are those who stand firmly opposed to writing tests to cover coded solutions. They claim things like “It costs more money to ‘waste’ time on writing tests.” or “I can write good code without ‘wasting’ time on writing tests.” or “I don’t know how so why bother?” or classically “No code can be written to test this.”
In spite of all the arguments (and there are certainly more than those I just listed) there is greater value in writing code tests than not.
From a developer’s point of view, there are quite a few good motivations to writing code tests, but for now, I thought I’d list the four that I think are at the top of the list for building quality, solid software solutions whether you have the perspective of a developer or not.
1. A well written test assists in thinking through a solution and forces the team to have a plan.
It is surprising how often anyone begins anything without thinking it through first. Even when we speak, many of us are often quicker to let words loose than to consider what we are going to say before saying it. But in the world of science and technology, an accident or poorly thought out solution may cost you an advancement, or financing, or worse, a good relationship.
2. Good tests help to prove the stability of a constructed solution.
Often times, writing software is compared to constructing a building. There are many similarities – an architectural blue print or plan is always a first step. Software is put together in sequence just like a building is put together in sequence, always starting with the framing and finishing with the “decor” or bells and whistles. As a building is constructed, inspectors come in and check to make sure that what is being built is good quality, and is safely and solidly constructed. Once something passes inspection that is the “proof” of its quality. Well written tests are just like a good inspector – they are the proof that the constructed solution is well crafted.
3. Unit and integration tests help to avoid regression when changes are made to the solution.
Sometimes when a change is made, especially with large, complex solutions, it is difficult to know whether or not that change will affect other areas of the software. Have you ever had a strand of Christmas lights where one single bulb being out affected all bulbs of that color? Wouldn’t it be great if there were a visible indicator as to which bulb was broken so that you didn’t have to check each and every bulb individually until you got the right one swapped out? Well written code tests provide that indication. When one piece of code is changed, there can be a ripple effect and well written tests can point to the exact method or function that caused the disruption and all the methods that were affected by it.
4. Tests can serve as notification when a change violates a business rule or assumption.
Every organization struggles with good communication, and even those that excel at communicating well still have moments when someone makes a change and forgets to inform every person necessary, or perhaps someone will need to change a rule but doesn’t remember that there is more than one reason that rule is in place. People are prone to forgetfulness and mistakes and well written tests will notify the team when a rule has been forgotten or mistaken. Good tests help to let us know when something has been forgotten or mistakenly changed or perhaps just flat out misunderstood. Good tests give an entire team a heads up when a rule or assumption should be modified to fit a previously unknown scenario, and they also serve as a double check against changes that perhaps shouldn’t have been made because of the rules and assumptions they violate.
Anything well-crafted is worth taking the time to ensure its quality, and software solutions are certainly no exception.