James Boston's Code Blog

A few more words about xpcshell testing.

The devmo tutorial explains how to write the tests. However, the information for adding tests to the tree is perhaps not totally clear because it geared towards extension developers:

You should store your tests near the source of code you want to test. For example, imagine you want to add tests for your component in extensions/myextension/mycomponent, you will add a tests/ directory. You can store different kind of tests here (reftests etc.), and for xpcshell, you should create a unit directory and store all your javascript files inside it. Example: extensions/myextension/mycomponent/tests/unit/test_foo.js. The unit name is important because for the moment the xpcshell unit tests framework recognize only this name (especially when you want to launch a single test with check-interactive).

Then you should create a extensions/myextension/mycomponent/tests/Makefile.in which will contain XPCSHELL_TESTS = unit. Of course, in the extensions/myextension/mycomponent/Makefile.in you will add tests/ into the DIRS variable.

In practice, the work of setting up directories and makefiles may already be done. Here's some bash to list all the modules that have xpcshell unit tests and where they are located:

If you're module has one, it's just a matter of dropping yours into the correct directory. For the most part, unit tests are found in module_name/tests/unit.

For example, here's an abridged version of the xpcom tree that shows the interface I want to test and the javascript file I use to test it:

To manually run all the tests in the unit directory:

Or to run just one:

New patch:
http://jamesboston.ca/patches/patch112808.txt

I've figured out how to move my unit test into the tree along with a few simple programs that are used by the test. There is an existing directory for unit tests at xpcom/tests/unit and that's where test_nsIProcess.js can now be found. I also created a new directory, xpcom/tests/simple-programs, that contains the source for, well, simple programs. When the tree is built, they get compiled into executables that I can use to test the functionality of nsIProcess. Links to the executables appear in obj-ff/dist/bin which is convenient for me.

Now it's just a matter of polishing the actual unit test code to make sure it covers every edge case. At the moment, it simply runs through all the functions to see if the return codes make sense.

One of the issues I've had with creating a unit test for nsIProcess is figuring out the full path to my unit tests within the build system.

The answer is much simpler than I expected.

This will return /home/james/mozilla/src/obj-ff/dist/bin which is exactly what I need.

The other issue is building a few simple executable files at compile time. I need binaries that do things like exit, never exit, and crash. (These are actually the files I need the full path for.)

Ted Mielczarek has pointed me in the right direction with regard to makefiles (which are my nemesis). Just write a TestProgram.cpp and then set SIMPLE_PROGRAMS = TestProgram in the makefile.

The only other stumbling block left is figuring out where the unit tests should go in the tree. I've been using the example file in the devmo tutorial. There is probably more makefile pain ahead.