ert: Interactive Debugging
4.2 Interactive Debugging
=========================
Debugging failed tests essentially works the same way as debugging any
other problems with Lisp code. Here are a few tricks specific to tests:
• Re-run the failed test a few times to see if it fails in the same
way each time. It’s good to find out whether the behavior is
deterministic before spending any time looking for a cause. In the
ERT results buffer, ‘r’ re-runs the selected test.
• Use ‘.’ to jump to the source code of the test to find out exactly
what it does. Perhaps the test is broken rather than the code
under test.
• If the test contains a series of ‘should’ forms and you can’t tell
which one failed, use ‘l’, which shows you the list of all ‘should’
forms executed during the test before it failed.
• Use ‘b’ to view the backtrace. You can also use ‘d’ to re-run the
test with debugging enabled, this will enter the debugger and show
the backtrace as well; but the top few frames shown there will not
be relevant to you since they are ERT’s own debugger hook. ‘b’
strips them out, so it is more convenient.
• If the test or the code under testing prints messages using
‘message’, use ‘m’ to see what messages it printed before it
failed. This can be useful to figure out how far it got.
• You can instrument tests for debugging the same way you instrument
‘defun’s for debugging: go to the source code of the test and type
‘C-u C-M-x’. Then, go back to the ERT buffer and re-run the test
with ‘r’ or ‘d’.
• If you have been editing and rearranging tests, it is possible that
ERT remembers an old test that you have since renamed or removed:
renamings or removals of definitions in the source code leave
around a stray definition under the old name in the running process
(this is a common problem in Lisp). In such a situation, hit ‘D’
to let ERT forget about the obsolete test.
Info Catalog
ert: Understanding Explanations
ert: How to Debug Tests