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