If you're writing any code for Mozilla, you sure have tasted how disturbing it might be to write some piece of code, then do a full build of the entire code base, and then testing your work, only to find that you need to make a small correction, and recycle the whole build and test process again.  This may waste a lot of time which can be used elsewhere, so here are two tricks that may come in handy.

Code changes only in JAR modules

Mozilla based projects package some pieces of the code which are interpreted at runtime in JAR archives.  These include JavaScript code, CSS stylesheets, XUL files, XBL bindings, etc.  If the changes you're making is only within such files, then all you need o do is to rebuild the corresponding JAR file.  So, for example, if you're making a change to button.css, then all you have to do to build a new version of the project you're testing is to issue the following command (if you don't use an objdir — and you should!):

cd /path/to/mozilla/sources
make -C toolkit/themes

Or this command if you're using an objdir:

cd /path/to/mozilla/sources
make -C objdir/toolkit/themes

And, voilà!  You can run and test your changes, and it took less than 10 seconds to build the new version (if you have a reasonably modern machine, that is).

Code changes to C++ modules

If you happen to be working on a C++ module, then you can use the two-stage build like this example.  Firstly, you should add the following to your .mozconfig (if it doesn't already contain those), and use an objdir:

ac_add_options --disable-static
ac_add_options --disable-libxul

These options make the compile process produce separate shared library modules that are dynamically-linked at runtime.  So, if you're making a change to, let's say, nsEventStateManager.cpp, then all you have to do is to build the shared component in which this file is being linked.  That is:

cd /path/to/mozilla/sources
make -C objdir/content/events

This compiles nsEventStateManager.cpp (with any other files which need to be re-compiled because of compile-time dependencies).  To actually link this file into the executable module loaded at runtime, you have to make the build directory as well.  This directory is usually named “build” and is located in the module's main directory (for example, netwerk/build), but there are some exceptions.  The build dir for uriloader is docshell/build, and the build dir for content, dom, editor and view is layout/build.  So, the next command to run is:

make -C objdir/layout/build

Which takes the resulf of compilation of nsEventStateManager.cpp and links it into a shared library to be loaded at runtime.  This is usually much more faster than a new build, unless you're making tree-wide changes.  Try it, and you'll never hack without it!