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 Archive ("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

• Hilfe, ich hänge beim Programmieren fest!
• The XY Problem Archive

Debugging in Ruby

• Include the byebug gem in your Gemfile. This provides debugging for your app.
• At any line, insert the command byebug or debugger.
• 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.
• Use the byebug README Archive and byebug's help command (check help 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 (e.g. by using git add -p). Never commit a debugging breakpoint.
• If you are debugging rspec tests, you can use rspec -b to print the full stack trace.
• If you encounter problems caused by the ActiveRecord and it's database mapping, you can run ActiveRecord's query methods in the rails console and it will log the exact database interaction with their related sql commands to the console and it's result.

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:

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 (e.g. by using git add -p). 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 from 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.
• 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.
  • You can put debug statements within Ruby code as well.
  • To check the server log, enter tail -f log/test.log in your terminal to print the server log while the test is running.
  • To print the full stack trace you can use cucumber -d ...

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
• You can also use the curl command in your terminal to print the response of a request.

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.