Debugging [1d]
When your code does not behave as expected, you can use a debugger statement ("breakpoint") at any point in your code. This statement will open a REPL ("console") that you can use to inspect the current state of the program and move the control flow ahead manually.
Use debugging tools to find the exact line in the code where your expectation does not match the actual behavior. Since we use open source for everything, we can always find that line. When you ask a colleague for help, they will be able to help you better when you have already located the issue.
Learning to help yourself and ask good questions
Debugging in Ruby
- Include the
byebug
gem in yourGemfile
. This provides debugging for your app. - At any line, insert the command
byebug
ordebugger
. - When you start your app and the Ruby interpreter passes this line, this will open a debugging console. Do this.
- Note that when your app is a web app, the console running your
rails server
will pause the server and show the debugging console. Your browser will "hang" while that debugging console is open. - Note that the byebug console is not a full
irb
console, even though it somewhat behaves that way.
- Note that when your app is a web app, the console running your
- Use the
byebug README
Archive
and byebug's
help
command (checkhelp help
for it's usage) to learn to do the following in the debugging console:- Understand your current position in the program
- Read local variables
- Call methods that are reachable from the current scope
- Switch into a full
irb
console and back to byebug - Move the program position one statement ahead
- Jump into the next method call
- Jump out of the current method call
- Exit debugging console and resume program
- You should be in a habit of reviewing your code before committing. Never commit a debugging breakpoint.
Different debugging libraries
Ruby has always had multiple gems for debugging. When you're working on a customer project you need to check the Gemfile
to see which one is used.
All Ruby debugging gems have the same basic functionality:
- Add a breakpoint
- Get an IRB-like console when the breakpoint is reached
A debugging gem will also offer commands to step through your program, but their names differ from gem to gem.
Each gem also uses a different expression to set a breakpoint:
Gem | Breakpoint |
---|---|
pry Archive | binding.pry |
byebug Archive | byebug |
debug Archive | binding.break |
Debugging in JavaScript
- At any line, insert the command
debugger
- When a modern browser's JavaScript interpreter passes this line, this will open a debugging console if developer tools are already open. Do this.
- Note that since JavaScript is single-threaded, you cannot interact with your app's frontend while the debugging console is open.
- Use the
Google DevTools debugging guide
Archive
to learn to do the following in the browser's debugging console:
- Understand your current position in the program
- Read local variables or
this
. Observe how Chrome will automatically show the state of local variables in the Sources tab. - Call functions that are reachable from the current scope
- Move the program position one statement ahead
- Jump into the next method call
- Jump out of the current method call
- Exit debugging console and resume program
- You should be in a habit of reviewing your code before committing. Never commit a debugging breakpoint.
Debugging in Cucumber scenarios
- If you haven't done so already, configure Capybara to open Chrome for scenarios tagged with
@javascript
. - When you use
Spreewald
Archive
you can open a debugging console at any line in your Cucumber scenario, by saying
Then console
. Do this. - Try this out form a debugging console:
- Use
page.find(...)
to inspect the current DOM. - In a
@javascript
scenario, observe the current frontend state in the Selenium-controlled browser. If you run Cucumber in a VNC buffer you might need to open a VNC viewer for this. Note how you can even use the developer tools in the Selenium-controlled browser to inspect the DOM or run commands on the JavaScript console.
- Use
- When a step fails and you don't know why it is often a good idea to open a debugging console right before the failing step.
Debugging network traffic
- Your browser DevTools have a Network tab. You can use it to observe outgoing network requests and their responses.
- Try this with an app like cards:
- Open developer tools and go to the Network tab
- Check Preserve log in the tab's settings so the list isn't cleared before a full page load.
- Switch between a few cards. What requests and responses do you see?
- Update an existing card. Find your form data ("params") in the the relevant request entry in the Network tab.
- Find out how to throttle the network traffic in your browser to simulate a slow internet connection
Debugging DOM changes
- In your browser you can right-click any element and choose Inspect.
- This will open a tree displaying the current state of the DOM. The tree is live, so it will be updated automatically when your DOM changes.
- Do this on the large hero photo at
https://makandra.com/
Archive
.
- Can you find the element for the photo?
- Observe how the DOM changes as the photos are rotated every few seconds.
Does your version of Ruby on Rails still receive security updates?
Rails LTS provides security patches for unsupported versions of Ruby on Rails (2.3, 3.2, 4.2 and 5.2).