Debugging xpcshell tests (and what they actually test)

Scenario: You’re working on a mozilla.org trunk bug, and you’ve got a xpcshell testcase. Great. Except that it’s failing. What you want to do is to set a breakpoint in your C++ code to figure out why the test fails, but to do that you need your debugger attached to xpcshell. Since the xpcshell test harnesses usually run straight through, and run without user interaction, you never have a chance to attach to the right xpcshell.

Until today.

After I got tired of fighting this scenario a couple dozen times, I decided to write a patch which could let you load a given xpcshell test, and manually run the test. Instead of trying to figure out the full list of JS files your test needs, now you can debug the one test.

From your objdir, you run “make SOLO_FILE=(filename) -C (target directory) check-interactive“. This launches xpcshell and loads your testcase. You can then attach a debugger and set your breakpoints. Example: make SOLO_FILE=test_import.js -C js/src/xpconnect/tests check-interactive

js>_execute_test(); runs the test. (You still need to name your test function in each file “run_test()“.)

js>quit(); exits the xpcshell.

Gory details in bug 382682.

One thought on “Debugging xpcshell tests (and what they actually test)”

Comments are closed.