How many times has it happened to you that you developed a feature, did the initial testing, and deployed the feature, but after a few days (or a few minutes, as it happened in my case once), you find that the deployed code has a big, smiling bug (that could have been easily found by testing)
If something similar has ever happened to you, then you’re at the right place.
In this brief article, we’ll look at some of the points that you should go through when you’re working on a feature, code fix, or refactoring, even if you’re done with it and you’re ready to merge your PR and deploy your code afterward. Below are some of the steps you can take to minimize the risk of deploying a bug.
- Try to Break your Code (trust me, you’re the right person for this job)
One thing that has helped me find bugs is my desire to break the application (like entering alphabets and special characters in numeric fields or exhausting the input field by entering an enormous value, etc.). Be creative! You, as the developer, are aware of your intentions when creating the feature. Try to think of other things that you did not account for.
Also, you can put yourself in the position of a casual user (who knows nothing about the code or the application) and try to mess around with your feature. This mindset would open new testing paths that you could not have imagined.
- Code Review (line by line, word by word)
The second step that I would recommend is to go through the code (as stated in the heading) line by line, word by word. This would drastically increase your chances of finding a typo.
This review also comes in handy when you copy and paste your code logic from one place to another and change some of the pasted code (like variables or function arguments, etc.) to re-use that code somewhere else. Chances are that you will miss some of the changes that you had in mind while pasting your code. This would result in very unexpected behavior. Hence, reviewing your code line by line and word by word should not be ignored.
- Code Coverage
Finally, you should try to do code coverage testing. Code coverage, in simple words, refers to the type of testing in which your focus is that each line of your code, especially when there is conditional logic (if-else) involved, should be run at least once. For achieving this goal, I have found it helpful to use breakpoints to keep track of the code that has been executed once by starting with a breakpoint in each block and removing the breakpoints when that block gets executed. This code coverage testing would not only test all lines of your code but also help you achieve end-to-end testing.
To summarize, a developer should try to break his or her code by doing creative things with it afterward; the developer should also review their code line by line, word by word, to reduce the chances of a typo being left in the code; and finally, test the code to execute each line at least once.
Finally, keep in mind that you, as the developer, have control over how many bugs end up in your code. As a wise man once said,
“If debugging is the process of removing bugs, then programming must be the process of putting them in.”
So, be careful when you code!
Author : Sajjad Ali
