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.
ifdef ENABLE_TESTS
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:
tools/test-harness/xpcshell-simple/example
to yourmoduledir/tests_type
, wheretests_type is something that describes your tests. You can of course use unit
or test
if you're not feeling creative.DEPTH
, MODULE
, and XPCSHELL_TESTS
appropriately:
DEPTH
should be a relative path pointing to <tt>mozilla/</tt>, e.g. if you're in <tt>netwerk/test</tt>, set DEPTH = ../..
MODULE
should be defined to test_yourmodule
or just yourmodule
-- either will work fine.XPCSHELL_TESTS
be a list of subdirectories of the current directory which contain xpcshell tests. You can of course just use the onetests_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