How do I debug ruby scripts?

Use Pry: http://pry.github.com

1. Print out the variables whenever possible. (This is called printf debugging) You can do this by running

   STDERR.puts x.inspect
   

   or

   STDERR.puts "Variable x is #{x.inspect}"
   

   If you want to make this easier to type, then you may want to use the exemplor gem.

2. Turn warnings on. If you're running ruby then run it with the -w switch (eg ruby -w script.rb). If you're running it from irb, and you're using a version of ruby prior to 1.9.2, type $VERBOSE = true at the start of your session. If you misspell an instance variable, once warnings are on you'll get

   warning: instance variable @valeus not initialized

3. Understand the concept of a binary chop (the following quote is from Practices of an Agile Developer)

   Divide the problem space in half, and see which half contains the problem. Then divide that half in half again, and repeat.

4. If you're successful with a binary chop, you may find that there's a single line that doesn't do what you expect it to do. For example

   [1, 2, 3].include?([1,2])
   

   gives a value of false, even though you'd think it'd return true. In that case, you may want to look at the documentation. Web sites for documentation include ruby-doc.org, or APIdock. In the latter case, you'd type include? next to the magnifying glass near the top right corner, choose the include? which has Array underneath it (if you don't know what class [1, 2, 3] is, type [1, 2, 3].class in irb), and you get to include? (Array), which describes what it does.

   However, if the documentation doesn't help, you're more likely to get a good answer if you can ask a question on how a specific line isn't doing what it should, rather than why an entire script isn't doing what it should.

1. You can print your variables out along the way
2. Turn on the -w (warnings) flag
3. Use a tool such as ruby-debug

All other answers already give almost everyting... Just a little addition.

If you want some more IDE-like debugger (not-CLI) and not afraid of using Vim as editor, I suggest Vim Ruby Debugger plugin for it.

Its documentation is pretty straitforward, so follow the link and see. In short, it allows you to set breakpoint at current line in editor, view local variables in nifty window on pause, step over/into — almost all usual debugger features.

For me it was pretty enjoyable to use this vim debugger for debugging a Rails app, although rich logger abilities of Rails almost eliminates the need for it.

As banister recommended: use pry! I can only agree on this.

pry is a much better repl than irb.

You need to add

require 'pry'

to your source file and then insert a breakpoint in your source code by adding

binding.pry

at the place where you want to have a look at the things (this is like triggering a breakpoint in a classic IDE environment)

Once your program hits the

binding.pry

line, you'll be thrown right into the pry repl, with all the context of your program right at hand, so that you can simply explore everything around, investigate all objects, change state, and even change code on the fly.

I believe you can not change the code of the method that you are currently in, so you can sadly not change the next line to be executed. But good ruby code tends to be single line anyway ;-)

The mother of all debugger is plain old print screen. Most of the time, you probably only want to inspect some simple objects, a quick and easy way is like this:

@result = fetch_result

p "--------------------------"
p @result

This will print out the contents of @result to STDOUT with a line in front for easy identification.

Bonus if you use a autoload / reload capable framework like Rails, you won't even need to restart your app. (Unless the code you are debugging is not reloaded due to framework specific settings)

I find this works for 90% of the use case for me. You can also use ruby-debug, but I find it overkill most of the time.

printf debugging

There has always been a controversy around debugging techniques, some people like to debug by print statements, some other ones like to dig deep with a debugger.

I'd suggest that you try both approaches.

Actually one of the old Unix men recently said, that printf debugging was a faster way to go for him at some points.

But if you are new at some job and need to understand a big blob of code, then it's really usefull to step throughout there, putting some breakpoints here and there, going along with it how it works.

It should give you some understanding how the code is weaved.

If you are new to some other peoples software, It might help you to step through there.

You'll quickly find out if they arranged it in a clever way, or if that's just a bunch of shit.