Requiring unit tests for code review isn’t the greatest motivation for people to write unit tests. Sure, it tries to make sure unit tests are written, but it doesn’t give the reason to write them.

In general, I like to ask “why?” to figure out why things are done, why they should be done, what are other ways to achieve the same goal?

I don’t remembering ever getting an explanation on why there was a requirement. I suppose the obvious answer was that we now have a testing infrastructure, and we don’t have many unit tests, so you need to write them. But still, that’s not a great motivation for writing tests.

So, why should you write unit tests?

1. Make sure your code does what you want it to do
2. Speed up development and optimizations/refactoring
3. Create better interfaces and functionality
4. Get other people to use your contribution
5. Make sure nobody else breaks your feature

This isn’t an exhaustive list, but these are things I’ve noticed from my own experiences.

Make sure your code does what you want it to do. The first reason is somewhat obvious, but it’s effect isn’t. I believe one big benefit is that it lets you change how you write code. Specifically, it speeds up your development in that you don’t have to completely think through what you’re doing. That might not sound too great, so I’ll try to give an example.

When working on word boundary matching for the AwesomeBar, I had automated unit tests set up with a set of pages and a set of searches, and it made sure searches matched on word boundaries (like spaces, dots, slashes and not after other characters). I needed to write a string processing utility that matched on word boundaries that would work for standard word boundaries as well as CamelCase and not break search for ideograph languages like Chinese.

I was never one for too much theory, so instead of sitting around and explicitly drawing out all the boundary conditions, I made simple code changes, recompiled, checked if the tests passed. Instead of sitting around for 10 minutes thinking deeply about how to deal with multiple word boundaries in a row, I made a 1 second change and ran the test to see that it passed.

The point there is that you can spend less time trying to reason about if the code will do what you want and just let the computer automatically do the checking. You already specified what the code should do with your test, and the computer can quickly make sure that they pass. This also relates to speeding up development (or perhaps avoiding my impatientness) because I don’t need to go through the long process of firing up a debug build to make sure my manually typed search terms find the expected pages — I don’t even need to make sure I have the right profile with the right set of test pages.

Speed up development and optimizations/refactoring. I mentioned speeding up optimizations and refactoring, but the former is basically a special case of the latter. Both tasks are making changes to the code without changing functionality. With automated unit tests set up, you can be sure that your refactoring changes don’t break expected functionality. For example, as I was optimizing the AwesomeBar to go faster and use less CPU cycles, I relied on the unit tests to make sure searches still provided the same list of urls.

In fact, one of my unit tests caught a bug in my first optimization because I forgot to check for javascript: URIs. The optimization reuses previous search results if the new search begins with the same text as the previous one, but we also do some special processing for javascript: URIs. Namely, we don’t show javascript: results unless you explicitly type out “javascript:” at the beginning of the query. So if you were searching for “javascript” and then typed “javascript:”, the optimization wouldn’t have shown any javascript: URIs because the previous result couldn’t have contained javascript: results.

Create better interfaces and functionality. Good APIs are fun to test. I enjoy writing AwesomeBar tests because I just need to provide some search words and a set of expected results. Simple. But you can also have better functionality because the process of writing tests makes you a user of the API. You start thinking about “what else” or “how could this be better.”

For a might-not-make-it-to-Firefox-3 feature of being able to restrict results to non-bookmarked pages or forcing matches on the url (by default), I wasn’t sure at first how things should interact if you have multiple “restricts” or “matches”. By writing the unit tests, I was able to easily look at all possible combinations such as “must match url and must match title”. Because I was writing the test, I noticed this potential issue and got it clarified; otherwise, it might have remained a not-well defined feature.

Get other people to use your contribution. I like to learn by example, so if I want to use something that I don’t know how to use, I search for existing uses of it in the codebase. A good description of a class/method is nice and all in the interface description, but seeing it actually used is much more helpful for me. Ideally test cases are written to test representative usages of a feature, so someone looking at the test code should be able to reason about how they should use the interface.

I’ve written up a couple unit tests for the PluralForm module, and they serve as additional examples of how to use PluralForm. I’ve written up some PluralForm documentation [developer.mozilla.org] on how to use it in Firefox and extensions, but without the unit tests, someone searching for PluralForm would have to rely on the current usage in the Download Manager. And relying on that would make things more confusing as one would have to look through a lot of unrelated-to-PluralForm download manager code.

Make sure nobody breaks your feature. You just worked really hard on adding a new feature. You don’t want it broken. I suppose an alternate motivation is that the blame goes to whoever breaks your test. If you didn’t have the test, potentially you would be stuck fixing it some weeks/months later. Also, with unit tests, it’s easier to see how the code is being used, so the person breaking the test should be able to fix it faster.

Tests aren’t just “for the future.” They help fix things now and help you go faster. And if you’re doing a lot of development and frequently touching the same piece of code such as having a huge stack of patches for a single file, unit tests help make sure patches can be applied without other patches, and if not, you know it wasn’t going to be safe to “cherry pick” a patch out of the stack and check it in.

I’m sure there are other benefits of writing automated unit tests, but I think this is a good starting list of motivations. Hopefully better than “why didn’t you write a test?!” 😉

Perhaps being stressed out and tired and after having some drinks isn’t the best time to write blog posts, but this is something I’ve been thinking about over the last few days. And I suppose in other conditions, I definitely wouldn’t be as open about this as I probably will be. I’m not accustomed to talking about personal things in person and especially not blogs. I tend to focus on objective things that “gets things done.”

So why did I work on Firefox?

Maybe I like to help people. Maybe I just like making things better when I see a problem that I can fix. Maybe I just want the world to be a better place. Or maybe I just like to work long hours. I do all this even if I don’t get much out of it. I suppose good thing about Firefox is that it’s open source and anybody can contribute and there are many people to help.

I recently sent Gerv an after-summer-of-code update and only then realized how much I’ve worked on. How much I wanted to help those people have a better experience. How many problems I saw that I could fix.

Both the download manager and location bar were being changed for the better, but there was so much more work to be done. Just to list a few things, I’ve added better download manager functionality with cross session resumable downloads, auto-pause/resume on sleep/wake, auto-resume on browser restart/crash, various fixes for saving files and some download status bar work.

Additionally, there’s the redesigned download manager UI work with the full listing of downloads and the ability to do multi-word search against any text shown in the list, and providing a way to display download progress / speed / times consistently as well some localization support for plural forms.

And of course there’s the work to make the location bar awesome. I wasn’t happy with the location bar return seemingly random results, so I decided to make things better. I started with the adaptive learning, but along the way I added in multi-word searching across urls, titles, and tags as well as word boundary matching. I also pushed patches for emphasizing all matches and cleaning up the display to be more compact as well as correct for foreign characters. There are also performance fixes to make results come back faster and render with less work.

Unfortunately, there were costs in making things better for everyone else. I haven’t been concentrating on my coursework, and my assignments have been partially completed when I turned them in. I’ve been tired and feeling burned out.

Just last week, I easily spent over 100 hours on Firefox stuff for my 1-week spring break. I wasn’t catching up on my assignment that was due the week before. Why not? There are still many things that I feel should be fixed.

I suppose I finally couldn’t take the stress from keeping things in, so I talked / cried / discussed with my Ph.D. advisor about things. He has been very good to me even though I haven’t focused as much on my research as I should have. Especially that he’s paying for my research assistantship and my tuition waiver. So I suppose unofficially, all my work on the Download Manager and the AwesomeBar has been funded by my advisor. (Apparently the download manager, location bar, and download manager again are the top 3 favorite features of Firefox 3 at mozillalinks, so I hopefully his money didn’t go to too much waste.)

But just working long hours isn’t really that bad. And I never really minded before, so I guess there must be something else.

It might be related to the improportionate amount of effort that I put in and what comes out. For those who followed the adaptive learning work to make the location bar into AwesomeBar, you might have noticed the code was pretty much ready when I first wrote about it in my blog early November. It wasn’t until a quarter of a year later (and almost 20 versions of the patch — mostly unbitrotting) that the patch got the appropriate bits twiddled so that it was high enough on the priority list to be reviewed and make it into Firefox 3.

I don’t think I did anything wrong in the process. I followed the rules and even provided extensive testcases. Perhaps there’s an issue with the code / review / approval path? For some reason, it just seems strange to me that only after people have done all the work writing the code, creating testcases, and getting reviewed does a final approval decision say yes or no.

It might also be that I try to fix too many things at once. I tend to have 10-20 patches on my mercurial queue stack, and the bases keep changing as things eventually get reviewed and modified. Maybe I’m creating artificial work unbitrotting myself, but that needs to be done when certain patches are deemed to be more important and I need to pull it from one end of my stack to the other.. Conflicts galore.

I realize it’s time to ship and changes need to cut back, so the process will have more hoops to jump through. But maybe I wasn’t expecting so many.

I still have a number of patches ready that add some neat things to the AwesomeBar such as being able to restrict searches to history or bookmarks and forcing matches against the url/title (additionally, you can set it up to force your queries to match against the url by default or only search non-bookmarked items). There’s also showing keyword queries and searching for strings as well as ignoring the protocol (e.g., “h” doesn’t match Http). Of course there’s tweaks to the adaptive learning to make it even better. But I suppose those will likely get to Firefox Next.

But back to unexpected hoops and tightening of the review process.. Earlier today, I was trying to make it easier to write download manager *test* code by adding a notification, and it was a very simple change to the download manager code. I simplified and cleaned up one of the testcases, but apparently it’s not good enough to review without at least 10 more testcases.

Also, I was trying to add in support for multiple-selection in the download manager so you can easily select multiple downloads to delete, pause/resume, etc. I even had a testcase locally that makes sure only selected items were deleted, but apparently the minimum number of things to test would be at least 20 more testcases.

But it’s getting late, and I suppose I’m feeling better already.. a little. Perhaps enough to even stick in an emotion 😉 . Maybe I’ll feel good enough by the morning to finally post about the new awesomeness of the AwesomeBar for Beta 5.. definitely with more pictures too. 🙂

How are people using the AwesomeBar in Firefox 3 Beta 4 [mozilla.com]? (Please comment. [ed.agadak.net])

There have been a lot of positive comments already: searching for multiple words like the domain plus title, adaptive learning that immediately brings previously selected results to the top.

But there are a few that say the desired results aren’t showing up. I’m not sure if they haven’t tried Beta 4, or if they’re just commenting based on previous versions. Or maybe they’ve installed extensions that revert the look of the location bar and haven’t really tried the new features.

Common complaints include typing “news” and getting results that match in the title instead of the url. However, that should be instantly fixed when the user selects the desired result from the list after typing out more of the url. Next time typing “n” will have the previously-selected page at the very top.

Below is a sample thought process that could only be possible with the AwesomeBar*.

I’m trying to find a news article I read yesterday..

The first result has news matching at the beginning of the url

Oh, it’s matching a lot of pages that I’ve tagged. I know it’s something in my history that I haven’t bookmarked.

Restrict results to non-bookmarked pages

Much better. I actually see some Firefox results that I was looking for to begin with. Let’s filter out the pages I don’t want.

History pages that match the url and title

Beta 2? Beta 3? I just want beta 4 news articles!

String matches for pairs of words like “beta 4”

Perfect! I love the awesomebar! Hehe, thanks shaver. 😉

* The screenshots were taken with a trunk build (win32, os x, linux [build.mozilla.org]) that contain some patches: 393678, 419656, 417441, 415397, 421315, 407946, 415403, 418257, 392143, 249468, 395161, 407204, 406257, 420437, 414326 [bugzilla.mozilla.org]. Feel free to try it out and see if it finds results better or just looks better (6 rows and smaller font size).

* edited downloads to include word boundary matching

It’s been exactly four months since I first wrote about the AwesomeBar [ed.agadak.net], and how it would become awesome with adaptive learning, which makes Firefox give you the pages that you want with just a single letter typed in the location bar.

Firefox 3 Beta 4 will have this feature. 😀 Everyone will be able to play with it in just a couple weeks.

Adaptive learning puts your most selected results first

The adaptive learning even works for the drop down menu without typing any words. So those who prefer using the mouse can benefit as well. But if you ever do select a page after typing some words, it will also learns to show those results when you click the auto-complete drop-down.

But that’s not all that’s new in Beta 4. There has been many improvements to the location bar since Places landed, and here’s a short list of changes since the first beta.

Beta 1: Search page titles and urls – not just the start of a domain; Match page tags
Beta 2: Two line view with title first; Emphasize first match in title then url
Beta 3: Global frecency for better ranking; Search bookmarked pages; Emphasize first match in both title and url; Unescape url-encoded URLs

Outside of adaptive learning for Beta 4, there’s also the ability to search with multiple words [ed.agadak.net]. I first wrote about the feature letting you find pages that match the domain and a word from the title.

It’s even better. You can also match against the tags you’ve added to pages, so you can just treat the tags as extra text in the page’s title, except they’re common across multiple pages. This means you can type a tag, a domain, and part of the title to get the exact page you want. As a bonus, the pages are treated like any other page, so they aren’t specially placed at the top of the list, and you don’t even need to type out the whole tag in the same order you tagged the page to match it. 🙂

So what else is there?

Well, it’s already Beta 4, and there isn’t much time left to keep adding features. But I’ve got some neat things that are somewhat geared towards more advanced users. Whether or not they make it in for the final version of Firefox 3 is in the air. I’ve already implemented them, so we’ll just need to see if people have time to review and approve the changes.

Only search pages with a star

First up is being able to restrict search to certain pages [bugzilla.mozilla.org] such as those that you’ve bookmarked, which have a star in the drop-down. You can type a single “*” at the beginning of the search and do the multi-word search as normal, except only bookmarked pages are searched. Also, you might notice that pages will show which tags they have [bugzilla.mozilla.org] and where they match.

Only search through history

On a similar note, you can also use “^” to find pages only from your history — pages that have not yet been given a star. I find myself using this type of search without additional search terms to find pages that I’ve frecently visited, and perhaps I would want to bookmark and tag them. One last special search is with “+” that restricts the search to tagged pages. Of course you can customize the character you want to type for the special search, so you can make it “!” or even “z” or more verbose “tags”. 😉

Show the keyword search

Another feature helps show a powerful feature of Firefox. Keyword searches. 🙂 Basically, they’re special bookmarks that you can create by opening the context menu on any search box of a website. You give the search a keyword, and then in the location bar, you type that keyword and the terms that you would have put into the box on the web page. You can easily search for content such as Wikipedia pages, YouTube videos, IMDB movie information, and more.

Except now, you get a keyword auto-complete entry [bugzilla.mozilla.org] showing which page you’ll be going to. Additionally, you can even reuse the same keyword for multiple searches because now you can pick which one gets used.

Search with phrases

Sometimes treating each word as a separate search isn’t quite enough, and what you really want is two words right next to each other. Perhaps you want to find that page that tells you how to bug mozzy (… 😛 ), but all your searches for “bug moz” finds bugzilla bugs! Just put the phrase in quotes and you can search quoted strings [bugzilla.mozilla.org]!

Emphasize all matches for all words

You might have noticed in the previous screenshots, multiple parts of the result get emphasized. For Beta 4, it’ll only emphasize words that match as the phrase, so most of the time, if you type multiple words, it won’t emphasize anything. The screenshot above shows “a” matching in all places [bugzilla.mozilla.org], not just the first. Additionally, all words/phrases [bugzilla.mozilla.org] are treated separately when showing matches.

For the very observant crowd, you might have already noticed the screenshots have a smaller font size for the page title [bugzilla.mozilla.org]. But additionally, the number of rows has been reduced from 10 to 6 [bugzilla.mozilla.org]. Hopefully, being able to find pages with multiple words against the title, url, and tags in additional adaptive learning will lessen the need to show 10 results by default. There will be fewer results for you to scan, but you can also filter pages more easily by typing another word that you know to be in the title or url.

We’ve come a long way since Firefox 2, and we’re getting really close to shipping Firefox 3. But hopefully there’ll be some time to get in at least some of these features. 🙂