Don't let bugs haunt your dreams
🏠 HOME
TUTORIALS
Unfortunately, in any ambitious piece of software, bugs are quite inevitable and can quickly become nightmares. On the other hand, fixing bugs is a very rewarding quest. So let’s turn those pains into recurring success!
When a bug is reported to you, first thing to do is to verify that you really face a bug, meaning that the software is not behaving as expected. Sometimes, you do not know the expected behaviour. In this case, compare observed behaviour with the one you get on a different environment or with some different credentials.
Quite often, some errors can be interpreted as bugs while this is the expected behaviour. In these cases, the question becomes why the user thought this was a bug and what we can do to avoid that. You know that you face a bug when you can proof that the observed behaviour differs from the expected one and that you can clearly expressed the differences.
As in real life, software bugs can leave their marks on their path. So first look for them!
Those footprints will help you to understand the bug and to later reproduce it.
In most cases, a given bug only arises in some very specific scenarios. Understanding the steps and their order that lead to a bug is the most crucial task you have to succeed in order to fix a bug.
To do so, the key here is to observe and then to connect the dots.
There are many things you can have a look at:
Fixing Bugs - If You Can't Reproduce a Bug, You Can't Fix It - DZone Agile
Once you have a clear understanding of the steps and conditions that lead to your bug, you can start trying to fix it. There is plenty of ressources that focus on that matter but we can of course list the following advices:
debugger for javascript,byebug for Ruby)How to fix bugs, step by step - Software Engineering Tips
It’s good to have confidence in yourself and your code but if you managed to first reproduce the bug, you now can and must check whether it finally flown away. Add some specs so that it will not be accidentally broken in the future. Also be creative and go one step further by trying to break your fix, find some new edge cases to cover.
Insert your breakpoint(s) in your code with byebug
def full_name(first_name, last_name)
byebug
return "#{first_name} #{last_name}"
end
Do the action needed to run the code you wish to examine closer (e.g. calling the method full_name in our example). Go check the local server you’re running in your terminal.
You’ll see something like this
Time to check what you can access in this context (e.g. what’s in a variable or methods, etc.) and manipulate those objects.
To do that just write the name of what you want to check in the terminal and press Enter( The terminal doesn’t show you what you are writing, but trust us: you’re writing something ) .
To go to the next line in your code: you can type n and press enter.
To exit byebug : write c and press enter until you’re out of your breakpoint(s).
Insert your breakpoint(s) in your code with debugger
const square = function(number) {
debugger
return number * number
}
Make sure to open your browser console before executing the action that’s going to run your code.
What it looks like
If you want to manipulate some objects or see what’s inside of them, go to the console and type you heart out.
Simply press the blue play icon to move out of the debugger. You can also click on the arrow icon to go to the next line in your code.
<aside> <img src="/icons/playback-previous_lightgray.svg" alt="/icons/playback-previous_lightgray.svg" width="40px" /> OS X Machine Setup
</aside>
<aside> <img src="/icons/playback-next_lightgray.svg" alt="/icons/playback-next_lightgray.svg" width="40px" /> SSH Tunnels
</aside>