Hunting the Shmoo

Dry versus Wet

As programmers, we are taught early on that code duplication is bad and should be avoided at all cost. It makes code less maintainable, reusable and readable. The DRY principle is very basic and fundamental to how most of us approach software design. If you aren’t familiar with the DRY principle, please take a minute to read the wikipedia page on it. The counterpart of DRY, is WET (write everything twice). In general, I agree that DRY is good and WET is bad. But I think there are a class of problems where the DRY approach can actually be harmful. For these types of problems, I will make a claim that a WET approach can actually work better.

Getting Started

tl;dr - It is possible to add more mach to your B2G repo! To get started, install pip:

$ wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py -O - | python

Install b2g-commands:

$ pip install b2g-commands

To play around with it, cd to your B2G repo and run:

$ git pull                 # make sure repo is up to date
$ ./mach help              # see all available commands
$ ./mach help <command>    # see additional info about a command

Details

Most people who spend the majority of their time working within mozilla-central have probably been acquainted with mach. In case you aren’t acquainted, mach is a generic command dispatching tool. It is possible to write scripts called ‘mach targets’ which get registered with mach core and transformed into commands. Mach targets in mozilla-central have access to all sorts of powerful hooks into the build and test infrastructure which allow them to do some really cool things, such as bootstrapping your environment, running builds and tests, and generating diagnostics.

Mach is an amazing tool which facilitates a large number of common user stories in the mozilla source tree. You can perform initial setup, execute a build, run tests, examine diagnostics, even search Google. Many of these things require an object directory. This can potentially lead to some confusion if you typically have more than one object directory at any given time. How does mach know which object directory to operate on?

This probably isn’t a groundbreaking revelation to most Mozillians, but it’s something I haven’t quite managed to put into words until now.

On the Tools and Automation team at Mozilla, the easiest way to describe what we do is to say “We try to make the lives of others within the community easier”. This is a vague statement, but it’s about as close as we can get without writing a small dissertation.

Before now running ‘classic’ unittests (mochitest, reftest, xpcshell, etc.) on B2G emulators has been a massive pain. The new recommended way of running them is through mach.

1. Update B2G repo if you haven’t already: git pull
2. Configure an emulator: BRANCH=master ./config.sh emulator
3. Build: ./build.sh
4. Run: ./mach mochitest-remote

OUTDATED

The steps in this article are no longer accurate. Pushing a custom command line is easier now. See here for more details.

Have you ever wanted to see the test results of a custom command line in try? Things like –test-manifest, –shuffle or –run-slower? Now you can! The process isn’t exactly optimized for the developer use case, but neither is it really difficult to do once you know how.

qqver is a Mercurial extension that forces mq to version all patch queues in the same repository. The syntax is the exact same as when doing normal patch queue versioning (i.e ‘hg init –mq’), except the repo is created one directory higher so it is able to track all patch queues. As with stock queue repos, new and existing patches are added automatically.

Hey! Check it out, I have crash stacks in my logs now! I know, I know, I took my sweet time. I’m sorry. I hope this doesn’t damage our relationship. Is there anything I can do to make it up to you? I want to help. I really do. It’s just. I don’t know. I guess I’ve been feeling under the weather lately. I must have caught a bug.

Throughout most of our B2G test automation deployment, we’ve been very conscious about not enabling too many tests simply because we didn’t have enough capacity on our test slaves to run them all. Regardless it was still bad enough as it was (many of you probably experienced very long wait times for results). Thanks to releng (and especially Rail Aliiev) we are now running most of our B2G tests in Amazon AWS which means we can be much more flexible in accomodating load.

As B2G continues to trod onwards to its release, there is still a lot of confusion about the level and state of test coverage it has. Back in November we started running mochitests, reftests and marionette/webapi tests on ARM emulators. Now we’ve also added xpcshell tests and for the most part we have these nice green letters to look at on TBPL that make us feel good about ourselves. But what is really being run? What is the meaning behind these letters “M”, “R”, “Mn” and “X”? Are there any causes for concern? Are there other tests being run that don’t show up on TBPL? What are the current automation priorities? What are the next platforms to use after emulators?

This blog post aims to answer these questions and more. It is a comprehensive snapshot of the current state of automated testing on B2G.