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 .
- 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" :) )
yourmoduledir/tests_type, wheretests_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 onetests_type directory here, but if you want to subdivide your tests by functionality, separate directories is the way to go.
- Reference the test dir in a parent makefile (<tt>yourmoduledir/Makefile.in</tt>):
ifdef ENABLE_TESTS DIRS += tests_type endif
- (Optional, but recommended) Add the new makefile to allmakefiles.sh (TODO: need more details about this)
- Reconfigure (e.g. with <tt>make -f client.mk configure</tt>)
- make/make check in <tt>yourmodule</tt>