Testing Rocks, Debugging Sucks
— Chapter 6 —
There seem to be some foolish souls out there who think that “if I don’t ever test my code, then I will find no bugs”. Their way of doing software development with poor test coverage might help them to meet their deadlines in the short term, but they are most definitely heading for a complete disaster in the long term.
Software constantly changes and evolves with each engineer’s code submission to the code repository. But each of these changes brings a risk. Changes in one class, function, or component can easily break something somewhere else in the code.
The best and pretty much the only way to protect against this risk is software testing.
Without proper testing, these bugs can go unnoticed and accumulate. Then they will start causing problems. If you are lucky, your build is going to break when you’re trying to compile and build your binaries, and then you’re going to spend time debugging the root cause of this build breakage. If you’re particularly unlucky, your server is going to fail at 3 am on a Saturday once you’re on-call, and by then you’re going to have to do your debugging.
Without proper testing, software is inevitably going to decay.
Here is another way of looking at it: Either you do your testing properly at the very beginning as you’re developing your software, or your customers are going to be doing the testing of your software as they use your services or products. Believe me, you want to go with option 1 rather than option 2. Your company’s reputation depends on it.
Never think that it would be a good idea to save time and deliver your product early to impress your customer by skipping or mitigating the testing efforts. Customers prefer using a product that works properly rather than receiving a faulty product delivered a few weeks/months faster.