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.

Contrary to popular belief, we (the A-Team) have been running mochitests, reftests, marionette tests and webapi tests on B2G in some form of continuous integration or another for about 5 months now. They’ve been reporting results to a TBPL look-alike called autolog, and were run on Amazon EC2 VM’s with emulators. This was a temporary solution to get something stood up quickly while we moved towards our ultimate B2G automation goal - tests running on Pandaboards and reporting to TBPL.

As of this week, while there are still no tests running on Pandaboards, I’m happy to say we have emulators running mochitests, reftests and marionette/webapi tests, all reporting to TBPL.

This quarter I’ve been focusing on getting reftests running on B2G, triaging them and fixing various issues. The purpose of this post is to outline their status, go over the work that still needs to be done and point out where I will need some help.

Sometimes I’d remember this awesome thing that I saw on Reddit awhile back and want to share it with someone. I’d try to find it through browser history or reddit search, but I wasn’t usually successful. Reddit search isn’t very good and I use Reddit a lot so my browser history for reddit.com is huge and unwieldy.

So in my spare time I decided to write Reddit History. It basically just keeps track of all the submissions you’ve viewed, and lets you filter them by sub-reddit and text search (regex).

Normally I don’t bother making top ten lists at the end of the year, but I was bored and figured, why not? So without further ado, here are my top ten albums of 2011.

1. Unexpect - Fables of the Sleepless Empire
2. The Decemberists - The King is Dead
3. Battles - Gloss Drop
4. St. Vincent - Strange Mercy
5. The Dear Hunter - The Color Spectrum
6. Fucked Up - David Comes to Life
7. Cut Copy - Zonoscope
8. Panda Bear - Tomboy
9. Phideaux - Snowtorch
10. James Blake - James Blake

Mozconfigwrapper is a tool inspired by Doug Hellman’s magnificent virtualenvwrapper. In a nutshell, mozconfigwrapper hides all of your mozconfigs into a configurable directory (defaults to ~/.mozconfigs), and lets you easily switch, create, remove, edit and list them. Mozconfigwrapper is Unix only for now.

So here in Toronto another cyclist was killed today. I’m a little bit frustrated with the state of cycling in Toronto in general. On one hand you have people like Mr. Ford who think that cyclists are always to blame and should be run off the road, and on the other you have cyclists who actually do run reds and wear black in the middle of the night giving the rest of us a bad name. I decided I need to write down my thoughts if for no other reason than to calm down. In an ideal world, cyclists would all respect the rules of the road and cars would always be alert for cyclists around them. However this will never happen so it is up to you, the cyclist, to ride cautiously.

While responsiveness is one of the main goals for Firefox this quarter, we still don’t quite have the means to measure and test our progress towards this goal. The good news is that there are, and have been for some time, several efforts to fix this problem. Back in June, Ted wrote some event tracing instrumentation that gives us a reasonable idea of when the browser becomes unresponsive. This event tracer is already being used by some Talos tests which gives us a good general idea of whether or not Firefox is more or less responsive than it was previously. What it doesn’t give us is a method for developers to write their own tests and determine whether a specific action or feature they are working on is causing unresponsivness.

At the beginning of September, I was asked to write yet another automated test harness for testing user responsiveness. Among other things, the harness needed to be capable of automating a wide range of user interactions in Firefox (such as opening context menus, clicking buttons etc). Oh and by the way this needs to be finished as quickly as possible.