Look Pa, it’s a ghost. No son, it’s my code
There is a time in my lifetime that I was super scared with my own code. Not because it will pop a ghost face suddenly on my tiny little laptop, but because I was so afraid to push that code to production that I might destroy my customer’s system. Is that ever happening to me? Sadly the answer is yes, and it took me three days full of agony and apology to stop the bleeding and hotfix stuffs. The most terrifying moment of my life to this date.
Then I started to think, I am tired with all of this fear but how do I get out from such condition? I did read many articles and discussions with my peers, friends, and even my supervisors. After all those tiring process, I finally found the answer and it always been there all along.
Testing
Yes, the answer is testing. This is a word that everyone already know, but little that we know that this word can actually help us eliminating our fear. Most of my deployments in the past would sent me to agonising night full of fear of breaking something. I never took a good sleep at night, at least for 2 days after the deployment happened. However, it all changed after I try to consciously add test to my code. By consciously, I literally spent 20% of my development time to really understand the code entirely and another 40% to test it based on my understanding to those particular codes. And yes, the rest of 40% are the specifications, real coding activities, no fun about that. And guess what? No more sleepless night, only happy faces onward.
So the next question is, how that 40% can help me sleep better at night? P.S does not contain sleeping pill
Test Coverage
Here’s the fun part. One thing that can measure testing quantitatively is testing coverage. Force has Newton as its unit, and Testing has Test Coverage as its unit. It tells you whether all of your functions and methods, all of your if else and switch case, and even all the lines in your code are covered in your test or not. And what do all of these mean?
Full coverage does not make your code becomes bug-free. The only bug-free code is no code. It also will not detect bad code. What it will help you is eliminating manual validation, thus becoming your safety net if your new code breaks something. If it worked before, and it does not after you add or change something, then it will most likely because of your changes. Take a look into this piece of code
// Your Function
function isBaby(age: number) {
return age < 5 ? true : false;
}// Your Test
expect(isBaby(4)).to.equal(true)
If you change your function logic, switching `<` to `>`, your test will no longer work. It indicates that your test no longer fits your code, and so does your customer code no longer fits your code, resulting a disaster in their end. This is your safety net before you destroy someone’s company and you should be grateful that something actually got your back to prevent you from doing silly thing.
Do I really need to aim full coverage?
Full coverage means 100% coverage. To be honest, reaching full coverage and passing all the tests will not eliminate your fear entirely. There is always a chance that you still miss something. We are still human after all. But, what it gives you is better assurance that your code is safe enough to be deployed. The probability of something is breaking is lower.
With these premises, it makes sense to aim for full coverage. Having a full coverage can still introduce unpredicted bug, let alone a low, medium, or even high coverage.
FAQ
What if I have hard time writing the test?
The dilemma is so intense here. If I skip testing the code, then I will not have full coverage. If I write the test for it, it will takes me hours to finish. My suggestion is to just do it. Aim for 100%, whatever it takes and that’s it. Remember, if your code is hard to test, it will be hard to maintain. And hard to maintain often leads to poor productivity and confidence. Consider having a test double (stub, mock, etc.) for short term solution or even refactoring for long term solution.
Do I need to write test for this super simple function?
Do not belittle simple basic code impact. Take a look again to my example above, and see how 1 character change in a simple function can make huge different. Test it to prevent bad things happen
Final Word
Based on my own experience, aiming for full coverage is super challenging. It is not an easy task, it often harder than actual implementation. However, by the end of the day all the hard works will pay off. Do not let broken window theory (one disorder can encourage another disorder to happen) holding you down. Remember to aim only for 100% coverage.
Finally, enjoy your fearless production deployment and have a pleasant and sweet dream tonight.
The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten
— Anonymous
