Debugging for Beginning Developers (Part One)
By: Kaelin Alexander
Tags: Debugging, Beginners Guide, Bootcamp, Ruby on Rails, Ruby

The most innocuous “Bug,” made by Volkswagen.

As we all know, the majority of time programming is spent in the error zone. And this isn’t a bad thing. Indeed, under the aegis of Test-Driven Development (TDD), errors aren’t problems, per se, so much as pathways to solutions.

For beginning programmers in particular, though, solving errors can sometimes feel like flying blind: you know a test isn’t passing, but you might not have any real idea where things have gone astray. This is intensely frustrating, because it can make your trial-and-error iteration a lot less intentional.

Enter debuggers. While not all coding languages or frameworks offer ad hoc debugging solutions, these are some tools that can help us all to find our way back towards MVP. As I continue to learn more languages and libraries, I’ll be adding to this list.

Debugging in Ruby

binding.pry | Documentation

Getting It Started:

As you might expect with any Ruby gem, before you can use pry you’ll need either to install it on an ad hoc basis with gem install pry, or you’ll need to add it as a dependency — gem “pry” — within your Gemfile. Don’t forget to bundle install.

Using It

Once you’ve made pry available, all you need to do is drop the line binding.pry wherever you’d like to establish your breakpoint.

Keep in mind that for that breakpoint to be hit, you’ll actually need to trigger the relevant code around it. So, you might drop the binding at the top of a route that you know will get hit upon a form being submitted.

To trigger the binding, you’ll simply need to submit the form while running your app in a browser.

Once the breakpoint is hit, pry exposes your program’s current state through CLI. From there, you can check on the values of variables, manipulate variables, perform simple calculations, and do whatever else you need to verify that your expected result is playing out.

Simply type the name of the variable, or issue the relevant Ruby code within the binding. None of this will actually change the state of, for example, your database, giving you free reign to test whatever you need.

Getting Out

Getting out of a pry binding is easy enough; simply type exit and you’ll return to your usual runtime Shell. When you exit, your program will resume; so, it will continue from whatever happens after the breakpoint.

Debugging in Rails

byebug | Documentation

Getting It Started

From at least version 5.0 onwards, Rails already includes byebug. If, for whatever reason, you don’t have access to byebug with default, simply add it to your project’s Gemfile — gem “byebug” — and then bundle install.

Using It

Byebug is essentially pry for Rails. To trigger a byebug breakpoint, simply drop byebug into your code at the relevant point. As with pry, in order to actually trigger byebug, you’ll need to trigger the relevant, surrounding code by taking the appropriate action within your app.

Just as with pry, once your program calls a breakpoint, byebug will allow you to check on — and manipulate variables — via a shell in your terminal. Keep in mind that the context for your variables — initially, at least, you can always continue through your code using n (next) or s (step-into) — will always be that of the breakpoint.

The full list of commands for byebug is printed if you simply type help from within the byebug shell.

Getting Out

To exit the byebug shell, simply type q. Your program will resume.

Debugging in Vanilla JavaScript

console.log()

There isn’t all that much to the trusty old console.log() method, but it is a powerful way to know which way is up when you’re in JavaScript.

Getting It Started

To use console.log(), simply drop the method into your JS code and pass it the parameter of whichever variable (or message) you need to check up on. console.log() will not stop the rest of your code from executing because it’s not a breakpoint.

Using It

Once the method is called, it simply outputs the value of the parameter you’ve passed to console.log(). To view this value, you’ll need to have your browser’s DevTools console open.

Getting Out

As mentioned above, there’s no “getting out” of console.log() because it isn’t a breakpoint.

“debugger” keyword | Chrome Documentation

If you need to use breakpoints in JavaScript, then debugger is your go-to. This JS statement will trigger a breakpoint whenever it’s reached in your code with DevTools open in a compatible browser.

Using It

Using debugger will vary a bit from browser to browser; however, in most cases it functions similarly to byebug or a binding: when the debugger keyword is hit within your code, the context for state is set according to the context in which the method was called.

From within your DevTools’ console, debugger allows you to check state. But, because this is JavaScript, that state has the potential to be much more capacious (so, you can check various values within the DOM, the BOM, etc. in addition to local variables).

In that regard, JavaScript’s debugger is, to my mind, a lot more broadly flexible than its Ruby equivalents.

Getting Out

DevTools in many browsers will allow you to step through your code after the breakpoint, line by line. There should also be options to continue running the code fluidly after the debugger keyword. You can also toggle options to enable or disabled all breakpoints, which will cause DevTools to ignore breakpoints entirely. To view these options for your browser of choice, simply check the relevant documentation.

If you’re simply done debugging for the moment, though, the best option is simply to remove the “debugger” keyword from your JS.

(Photo by Reid Naaykens on Unsplash)