Previous: Understanding Explanations, Up: How to Debug Tests [Contents]

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

Previous: Understanding Explanations, Up: How to Debug Tests [Contents]