While running all the test cases there are chances some might fail. In this
chapter we take a look at the tools that we can use to debug our code to figure
out why the failure occurred and to fix it.
Let's run a test file which has been taken from the "granite" application, but
has been modified to make sure some test cases will fail for debugging purposes.
The following are the different failures that we may encounter:
Here on the final line of the output we get an summary of the test we ran, we
can see 28 assertions where made in 13 runs (which means 13 functions were
executed) and in which 4 assertions failed.
It's easier to fix the failures when we can take a look at it one by one. Rails
provides us an easy a way to do this. Lets look at the output we got from
running the test again.
Running an single test
In the above code snippet shown in last section, the highlighted line shows a
line number after the file name. If we take a look at task_test.rb we can see
that line 62 is the start of the test function which failed:
By running rails test test/models/task_test.rb:62 we can see that rails runs
only the method corresponding to the line number mentioned:
Here from the final line of the output we understand that only "1" test ran
which had "2" assertions and "1" failed. If we take a look at the function
definition we can see the second assertion failed here.
Now we know where exactly the issue is and what the expected and actual values
are. Sometimes it might not be obvious from the failure details and we might
need to do a deeper analysis.
Debugging using puts
From the test we know that we are calling Task.create!. Lets navigate to where
the actual method is written. There we can add puts statements to figure out
what might have gone wrong. This is more or less a hacky way of getting the job
done.
Here we need to add puts statements to test/models/task_test.rb:
By adding the above statement, the value of the puts statement is now printed
when we run the test again:
From the logs it is evident that it is a spelling mistake that caused the test
suite to fail. But this puts method becomes a hassle if we want to try change
or view multiple variable values. And more importantly we should never commit
code which has puts statements.
Debugging using byebug
To achieve the same result as the above method we can also use the byebug gem
to get a more powerful and interactive way to debug.
Example:
The debugger will run byebug which is a gem which has been already installed.
This gem requires no additional configuration. Now when we run the test:
We can see that byebug has set a breakpoint right after the line where we
specified byebug.
Let's say we want to print the current value of the variable slug_candidate.
For such cases we can just enter it to the terminal and we will get the output
in the current scope's context:
We can also change the value of variables by:
byebug gem has a lot of options which we can see by using the help command.
Some useful ones to know are:
continue - it runs until the next breakpoint is reached or the program is
terminated.var local - it shows all the local variable in current scope.break LINE_NO - it sets additional breakpoint in LINE_NO.
