These free mini-courses will give you a strong foundation in web development. Track your progress and access advanced courses on HTML/CSS, Ruby and JavaScript for free inside our student portal.
Scroll down...
You'll spend a LOT of time debugging your code. If you've followed the higher level concepts we introduced over the past few lessons (especially about using many small methods and classes), then you're in a good position to quickly debug the code. Even so, following a good debugging approach will help you save a lot of time in the long run.
In this very brief lesson, we'll lay out a debugging approach and introduce you to a few tools which can make your life easier. In particular, we'll show you the Pry REPL which should replace IRB as your favorite command line tool. The further along we get, the more useful Pry will become, so best start getting used to it now!
binding.pry
) if you need more backup.There's a gem called byebug
which lets you pause your code execution in the middle so you can manually step through it to see what might be wrong. We won't dive deeply into it but it's a useful tool to get accustomed to on your own because you no longer need to run your code in your head -- Byebug keeps track of everything for you.
You'll find debuggers similar to this regardless of which language you pick up. They're that useful. In fact, we'll cover the very similar pry
debugger in just a sec which we recommend over just plain byebug
.
To use the vanilla byebug
gem, simply install the gem, include it in your code, and then run it at the specific point where you think the failure might be by using the byebug
method:
# CLI
$ gem install byebug
# my_script2.rb
require 'byebug'
def buggy
byebug #<<<<<<<< where byebug will stop the first time
puts "I'm a buggy method!"
[1,2,5,0,1].each do |num|
1000/num
end
end
# IRB
> load 'my_script2.rb'
=> true
> buggy
[1, 9] in my_script2.rb
1: require 'byebug'
2:
3: def buggy
4: byebug
=> 5: puts "I'm a buggy method!"
6: [1,2,5,0,1].each do |num|
7: 1000/num
8: end
9: end
(byebug): # <<< this is the command prompt
When you run byebug
, you'll jump into a REPL (live interactive code) session just like IRB. You can then step piece-by-piece through your code and investigate what variables are at every point along the way.
Read the documentation on Github for basic instructions or the how-to Guide for more details.
Helpful commands:
step
steps you one additional increment through the programENTER
will continue the last command (e.g. step
)p
followed by a variable name will print the value of that variablequit
/q
/exit
leave Byebug.Note: Byebug only works for Ruby 2.x. If you're using Ruby 1.9.x, use the debugger
gem instead
We'll leave it up to you to experiment with this particular gem, though we recommend you actually use the very similar Pry Debugger.
You've probably been using IRB as your REPL of choice so far just because it comes with Ruby. IRB is pretty nuts and bolts -- it gets the job done well and that's about it. It's dry and functional, just like the command line should be...
Pry is a different story. It has all the features of IRB plus all kinds of useful bells and whistles that will make your life MUCH easier. It's a free gem that's easy to download and use and, as you'll see later, it's got some really powerful features and extensions. And it's colorful!
Pry is a gem like any other:
$ gem install pry
To use it, just type pry
into the command line instead of irb
:
$ pry
> # start REPL-ing!
Remember the byebug
gem from about 30 seconds ago? Pry natively gives you very similar functionality and the commands are pretty much identical. If you miss some of the extra commands that Byebug has, there's a pry-byebug
gem which does exactly the same thing for Pry.
We recommend you use Pry (via binding.pry
statements) to debug instead of running the Byebug debugger in IRB.
To debug with Pry, you can add a binding.pry
statement in the middle of your code and it will cause the Ruby script to jump into Pry just like you saw above with Byebug. The syntax for this is the same as with Byebug. You can inspect variables as if you're in the middle of a normal Pry or IRB session.
The most common reason for doing this is to verify the state of your program when a certain point has been reached.
For example, you might have the attack
method of your Viking running but nothing actually seems to happen. So you can put the binding.pry
line at the top of the method and inspect your script's state from that exact point. You might realize that, oops, the @weapon
variable is set to nil
so you aren't actually doing any damage. You forgot to pick up a weapon first!
require 'pry'
class Viking
...
def attack(recipient)
binding.pry
...
end
end
Here are a few other useful features of Pry which you can consider supplementary. You don't need to go out and learn the whole scope of the gem right off the bat -- it's best to get used to it first and then gradually start picking up new tricks. The Pry Documentation is a useful place to pick up new tricks and some creative Googling will reveal the rest.
inspect
statements to save some time when checking out variables. For instance, try self.inspect
to see the state of the current binding.binding.pry
in a while
loop), even typing quit
in Pry will just jump to the next binding.pry
statement. To fully quit the script, type exit-program
or !!!
.