Unit Tests For Mozbase


An idea of unit testing mozbase is proposed after having a good discussion with jhammel, jmaher, ctalbert (members of ateam). Actually, it is not just writing better automated test codes but a total refinement of mozbase unit-tests including unittesting framework in such a way that it will reduce complexity of code and will be efficient. Following are the details of the project and the proposed plan of action.


Implementing unit tests for mozbase modules using unittest framework with proper refactoring, minimum boilerplates and better test coverage. Doing sanity checking, resulting in efficient test codes.

Benefits to Mozilla community

  • Implementation of mozbase tests with less complicated tests and Unittesting framework would certainly result into an improved testing mechanism and error handling in mozbase.
  • Improvement in the test coverage will result in improvement of code quality of mozbase.
  • A detailed documentation on the work to help the contributers for further improvements on the work.
  • Writing unit-test will help in deep extensibilty to the behaviour of mozbase code and eventually results in solving many of the issuses related to mozbase-testing on bug tracker

Project Details

The aim of the project is not just quality assurance of mozbase but to provide a proper implementation of Unit testing framework rather than just a POC(proof of concept). It has far greater goals. Mozbase is so important that all of Mozilla’s test harnesses use mozbase to some degree, including Talos, mochitest, reftest, Autophone, and Eideticker. But the Current version of mozbase lacks proper unit tests and has poor test coverage. This project deals more about writing new efficient tests and complete refinement of old written mozbase tests using unit testing. The idea here is to dug deeper into testing to provide and maintain robustness and quality of mozbase. It is also important that the new tests should be less complex and more efficient. It should have more automated behaviour and minimum or no boilerplates. It should also pass pep8 and pyflakes testing.

One other feature of the framework should be that it should be sustainable and support further improvements. It means that if the tests need to be implemented further because of addition or enhancement of new feature(s) or tests need to be modified after a year or something, only slight change in the fixers should be enough and an automated process would be taking care of implementation of respective fixers to the tests. Since, it would be quite troublesome to implement all the tests again and again with each new modification or new release of mozbase dependencies, this feature is quite necessary from development perspective.

Tools Required During Development

  • Python Unittesting framework
  • Coverage
  • Pep8
  • Pyflakes
  • Vim (IDE)

The outline of my work plans

Modules of the mozbase which will be tested are :

  • moznetwork
  • mozprocess
  • mozcrash
  • mozdevice
  • mozfile
  • mozhttpd
  • mozinfo
  • mozinstall
  • mozlog
  • manifestdestiny
  • mozb2g
  • mozprofile
  • mozrunner

These modules further consists of different submodules that will be unit tested.

Schedule of Deliverables

The project is planned to be split across following weekly phases:

[Test Week 1] Adding unit tests for mozinfo and moznetwork.

[Test Week 2] Writing tests for mozfile and mozhttpd

[Test Week 3] Tests cover sub-modules of mozprofile.

[Test Week 4] Continuation of tests for sub-modules of mozprofile

[Test Week 5] Creating tests for sub-modulese of mozprocess

[Test Week 6] Continuation of tests for sub-modules of mozprocess

[Test Week 7] Adding tests for mozB2g, mozcrash and mozinstall.

[Test Week 8] Writing tests for mozdestiny.

[Test Week 9] Test for mozrunner sub-modules.

[Test Week 10] Adding tests for mozdevice sub-modules.

[Test Week 11] Continuation week for mozdevice

[Test Week 12] Final week for mozdevice and to polish the work before submission


  • Tests covering mozdevice, mozprocess and other core modules of mozbase.
  • Contribute to the overall code quality by uncovering issues with the unit tests
  • Less complex test infrastructure
  • More efficient testing mechanism


Install build prerequisites

Before building Firefox, we will need the build tools listed below and a few gigabytes of free disk space. Builds will be slow unless we have at least 2GB of RAM.


Run the following commands in a shell to install the needed tools:

Ubuntu users:

sudo apt-get build-dep firefox
sudo apt-get install mercurial libasound2-dev libcurl4-openssl-dev libnotify-dev libxt-dev libiw-dev mesa-common-dev autoconf2.13 yasm uuid

Debian users: Same as Ubuntu, but replace the first command with sudo apt-get build-dep iceweasel


sudo yum groupinstall 'Development Tools' 'Development Libraries' 'GNOME Software Development'
sudo yum install mercurial autoconf213 glibc-static libstdc++-static yasm wireless-tools-devel mesa-libGL-devel alsa-lib-devel libXt-devel

Getting the source

Getting the latest source code from Mozilla’s Mercurial code repository. It may take a while, it’s a lot of code!

hg clone http://hg.mozilla.org/mozilla-central

Build configuration (optional)

By default, the build system creates a release build of Firefox roughly equivalent to the official Firefox release builds. If that’s not exactly what you want, there are many build configuration options to choose from, although it’s strongly recommended that you only use options that you fully understand. The normal way to specify build options is to place them in a file called ‘.mozconfig’ at the root of your mozilla source tree. For example, to create a debug build instead of a release build, that file would contain:

ac_add_options --enable-debug

For more on configuration options, see the page Configuring build options.


make -f client.mk

How to update and build again

For pulling the latest changes and update the code in your mozilla-central working directory, run the command:

hg pull -u

Then just re-run the “make -f client.mk” command above. make will only recompile files that changed, but it’s still a long haul.