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
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
- 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
defuns 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.