Writing a test is good, but it is even more helpful if that test gets executed. We have various automation tools that help make this possible. The first link, though, is the "
check" target in a Makefile. If a test is added, that test or its directory needs to be mentioned in a Makefile.in file somewhere so that the build system knows about it.
To add a test that is written in C or C++ and which is called as a standalone executable, a few things must be done. For standalone executables, if one sets up the right variables, then the rules.mk file will do lots of magic and most of the heavy lifting. A simple example of adding a test is in .
Here are the simple guidelines for adding an xpcshell test to the build system.
- For now, enclose your test-related code (in the makefile) with
- Run the test program from the "check" target in the makefile. (example to run the TestCookie program)
- In the test program:
- If the test fails, exit with a non-zero status and/or print the string "FAIL" to stdout
- If the test passes, exit with a zero status and don't print the string "FAIL" (bonus points for printing "PASS" :) )
Write the test so that you expect it to pass on all platforms, since if the test fails, the tree will go orange (once we've set this up - see bug 352240 for status).
For example, to add an xpcshell test to a module, do the following:
yourmoduledir/tests_type, where tests_type is something that describes your tests. You can of course use
testif you're not feeling creative.
- In <tt>yourmoduledir/tests_type/Makefile.in</tt> change
DEPTHshould be a relative path pointing to <tt>mozilla/</tt>, e.g. if you're in <tt>netwerk/test</tt>, set
DEPTH = ../..
MODULEshould be defined to
yourmodule-- either will work fine.
XPCSHELL_TESTSbe a list of subdirectories of the current directory which contain xpcshell tests. You can of course just use the one tests_type directory here, but if you want to subdivide your tests by functionality, separate directories is the way to go.
ifdef ENABLE_TESTS DIRS += tests_type endif