667
edits
Changes
no edit summary
[[Dive into Mozilla]] > [[Dive into Mozilla Day 4]] > Mozilla Unit Testing Lab
== Overview ==
This lab is designed to give you first-hand experience writing a build-time xpcshell unit test for your XPCOM component. This lab will also serve as a starting point for our discussions of bugs and bugzilla.
'''NOTE: At the time of writing (February 28, 2007), this lab does not work due to bug [https://bugzilla.mozilla.org/show_bug.cgi?id=371329 bug 371329]. While this is regrettable, it still shows an important concept, and further, deals with the reality of bugs in Mozilla.'''
== Instructions ==
Mozilla currently uses three unit test methods:
# The first is '''xpcshell''' for C++ unit tests that run on the command line. These are the best method to use whenever possible. Using them effectively requires composing code as stateless functions that return values whenever possible--always a good practice.
# Second, since xpcshell tests are not always possible (i.e., a lot of code terminates at OS paint functions that return void, or depends on aspects of the entire browser), so called '''reftests''' are used. A reftest compares two screens side by side.
# For complex JavaScript and integration bugs, we have '''mochitest''', based on the DHTML framework '''MochiKit'''. Mochitest is very flexible and powerful.
For purposes of testing our FirstXpcom component, we will use xpcshell tests. This will allow us to easily write tests to insure the functionality of our class's methods.
You're correct that you find too many tests in the tree :/. We're working on that. browser/components/places/tests have some good examples.
* Now create some Unit Tests for your component so you can easily test things as you go (see the following for more details -- http://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests)
- mkdir mozilla/extensions/weblock/test
- cp mozilla/tools/test-harness/xpcshell-simple/example/ mozilla/extensions/weblock/test
- edit mozilla/extensions/weblock/test/Makefile.in to be:
-----------start--------------
DEPTH = ../../..
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
include $(DEPTH)/config/autoconf.mk
MODULE = weblock
include $(topsrcdir)/config/rules.mk
_TEST_FILES = test_all.sh
_UNIT_FILES = head.js \
tail.js \
$(NULL)
# Not sure if I need to alter these...
libs:: $(_UNIT_FILES)
$(INSTALL) $^ $(DIST)/bin/test-harness/xpcshell-simple
libs:: $(_TEST_FILES)
$(INSTALL) $^ $(DIST)/bin/
----------end-------------------
- Add the following to mozilla/extensions/weblock/Makefile.in
ifdef ENABLE_TESTS
DIRS += test
endif
- rebuild your Makefiles like so:
cd mozilla/objdir
../build/autoconf/make-makefile extensions/weblock
make
- finally, run your test suite once (it is empty right now, but this is how you do it):
make check
== Resources ==
* [http://developer.mozilla.org/en/docs/Mozilla_automated_testing Mozilla automated testing overview]
* [http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test How to add a build-time test]
* [http://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests Writing xpcshell-based unit tests]
* [http://developer.mozilla.org/en/docs/Creating_reftest-based_unit_tests Creating reftest-based tests]
* [http://lxr.mozilla.org/seamonkey/source/browser/components/places/tests/ Examples of good xpcshell tests, from mozilla/browser/components/places/tests]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=371329 bug 371329]
== Overview ==
This lab is designed to give you first-hand experience writing a build-time xpcshell unit test for your XPCOM component. This lab will also serve as a starting point for our discussions of bugs and bugzilla.
'''NOTE: At the time of writing (February 28, 2007), this lab does not work due to bug [https://bugzilla.mozilla.org/show_bug.cgi?id=371329 bug 371329]. While this is regrettable, it still shows an important concept, and further, deals with the reality of bugs in Mozilla.'''
== Instructions ==
Mozilla currently uses three unit test methods:
# The first is '''xpcshell''' for C++ unit tests that run on the command line. These are the best method to use whenever possible. Using them effectively requires composing code as stateless functions that return values whenever possible--always a good practice.
# Second, since xpcshell tests are not always possible (i.e., a lot of code terminates at OS paint functions that return void, or depends on aspects of the entire browser), so called '''reftests''' are used. A reftest compares two screens side by side.
# For complex JavaScript and integration bugs, we have '''mochitest''', based on the DHTML framework '''MochiKit'''. Mochitest is very flexible and powerful.
For purposes of testing our FirstXpcom component, we will use xpcshell tests. This will allow us to easily write tests to insure the functionality of our class's methods.
You're correct that you find too many tests in the tree :/. We're working on that. browser/components/places/tests have some good examples.
* Now create some Unit Tests for your component so you can easily test things as you go (see the following for more details -- http://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests)
- mkdir mozilla/extensions/weblock/test
- cp mozilla/tools/test-harness/xpcshell-simple/example/ mozilla/extensions/weblock/test
- edit mozilla/extensions/weblock/test/Makefile.in to be:
-----------start--------------
DEPTH = ../../..
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
include $(DEPTH)/config/autoconf.mk
MODULE = weblock
include $(topsrcdir)/config/rules.mk
_TEST_FILES = test_all.sh
_UNIT_FILES = head.js \
tail.js \
$(NULL)
# Not sure if I need to alter these...
libs:: $(_UNIT_FILES)
$(INSTALL) $^ $(DIST)/bin/test-harness/xpcshell-simple
libs:: $(_TEST_FILES)
$(INSTALL) $^ $(DIST)/bin/
----------end-------------------
- Add the following to mozilla/extensions/weblock/Makefile.in
ifdef ENABLE_TESTS
DIRS += test
endif
- rebuild your Makefiles like so:
cd mozilla/objdir
../build/autoconf/make-makefile extensions/weblock
make
- finally, run your test suite once (it is empty right now, but this is how you do it):
make check
== Resources ==
* [http://developer.mozilla.org/en/docs/Mozilla_automated_testing Mozilla automated testing overview]
* [http://developer.mozilla.org/en/docs/How_to_add_a_build-time_test How to add a build-time test]
* [http://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests Writing xpcshell-based unit tests]
* [http://developer.mozilla.org/en/docs/Creating_reftest-based_unit_tests Creating reftest-based tests]
* [http://lxr.mozilla.org/seamonkey/source/browser/components/places/tests/ Examples of good xpcshell tests, from mozilla/browser/components/places/tests]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=371329 bug 371329]