Archive for March, 2008
AwesomeBar Awesome Feature #832 March 28th, 2008
A friend of mine mentioned how awesome the new Firefox 3 beta is last night while we were playing a little Halo. “I know,” I told him, maybe a little cockily.
Undeterred, he plowed on, “the best new feature is, you know how you can collapse the toolbar and location bar on the Mac? With that little capsule button in the corner?”
“Yeeaah,” I offered, eager to hear where this was going, figuring he was going to say something like, you know it makes the browser area bigger, right?
“Well, now when you’ve got it collapsed, you can hit Cmd-L and a little Location Bar drops down.”
I let this sink in for a minute, realizing I was in uncharted territory.
“You mean I can hit Cmd-L and a Location Bar appears out of nowhere?” I asked incredulously.
“Yeah! It totally saves all kinds of space on my MacBook!”.
“O.M.G.” I think I said.
So, yeah, that little useless capsule button? Not so useless anymore. And having the full awesome power of the AwesomeBar available on Cmd-L in a collapsed toolbar? I can’t even tell you how cool that is.
Posted in Firefox, Mozilla | Comments (15)
Mochitest By The Numbers March 27th, 2008
In an email discussion yesterday, Schrep posed the perfectly cromulent question, how many unittests are we running and where did they come from? A good chunk of our testing comes from a few popular JavaScript programming libraries that some of our more intrepid test coders translated to run inside Mochitest. I knew we’d translated jQuery, Scriptaculous and Mochikit’s own test frameworks, to name a few, but what else was in there? And what portion of the 50,000 odd mochitests were from large external frameworks?
I spent the afternoon grabbing a new tree and running through a Mochitest run and looking at the output in Numbers. What follows is my simple analysis of the contents of Mochitest on Mac – the numbers are slightly different for other platforms but comparable.
- External sources 4555
- Mozilla contributors 43943
I want to be clear that these numbers may be slightly misleading. I can’t point at a single one of these and say with utter certainty that “that is a single unittest”. When we asked David Baron about the 20-odd-thousand tests included in Layout/Style, he told us:
There are a bunch of tests that test things combinatorically. In other words, for a long list of potential values for CSS properties, testing a large number of things related to that value’s parsing, serialization, and computation through different APIs.
Rob Sayre also had a note of caution regarding these figures:
The definition of what constitutes a single test is pretty fluid. I would just say “tens of thousands”
What we can say then, with some certainty is that Mozilla contributors have written, constructed or otherwise created tens of thousands of unit tests in just over 1 year. We’ve also outnumbered the external tests included in our test code by nearly 10 to 1. Areas we’re testing include, but are by no means limited to: content, canvas, layout, chrome, docshell, HTML parsing, XUL, … really too many areas to list like this. See the analysis doc for details.
I think this is a phenomenal achievement and would like to thank everyone who’s contributed. Clearly Mozilla has become a very test-focused project and this has enabled us to create better builds with demonstrably fewer regressions on nightlies and betas.
There’s always more to do. The external test-suites we’ve included could stand to be updated and augmented. Below are a set of bugs John Resig recently filed. If you’re a developer looking to hone your mochitest skills or want to contribute to our growing population of tests, pick one of these up and take a crack at it.
- https://bugzilla.mozilla.org/show_bug.cgi?id=424813
- https://bugzilla.mozilla.org/show_bug.cgi?id=424814
- https://bugzilla.mozilla.org/show_bug.cgi?id=424816
- https://bugzilla.mozilla.org/show_bug.cgi?id=424818
- https://bugzilla.mozilla.org/show_bug.cgi?id=424819
- https://bugzilla.mozilla.org/show_bug.cgi?id=424820
Tags: Testing
Posted in Mozilla, Testing | Comments (1)
Moved March 17th, 2008
Awhile back, we made a slight organizational change. Alice Nodelman, Mikeal Rogers, Chris Cooper and myself made a lateral shift to join forces with John O’Duinn, Rob Helmer, Ben Hearsum, Nick Thomas and Chris Cooper on the Build & Release team to create a larger, many-limbed crime-fighting robot. (Astute readers will note that Coop is actually two people) The reason for this was simple: Build & Release uses the same tools we’ve been using to drive the automation systems behind Talos, JS Testing and the Unittest machines. I think we’ve settled on the name of “Release Engineering” to describe this new beast and John O’Duinn has created some new Bugzilla components to reflect this.
What does this mean to you, the developer/tester/user? If you find a bug in one of the automated systems, you should now file that under “Mozilla.org:Release Engineering” in Bugzilla. I’ll still be monitoring Core:Testing but that should be used predominantly for Mozilla-related test harnesses and tools. We’re currently in the process of triaging Build & Release bugs and relevant bugs under Core:Testing and hope to have them re-assigned and re-bucketed within a week or two.
In other moving-related news, I’ve managed to reposition myself “closer to Greenland” as some have quipped. This shouldn’t really affect my availability for those of you in the West as I’ve shifted my hours up to compensate – this just means I get to sleep in a little more. What has been an issue is my ongoing struggle with Aliant.net to get my internet up to the speeds I’m actually paying for. They have a few more days to get this fixed and then I’m going to open up the bidding.
To the shamrock-wearers, happy St. Paddies day!
Tags: Build
Posted in Build, Mozilla | Comments (0)