Test cases make bad law

Testing seems to be the topic du jour this weekend… A few remarks.

I don’t think this is a discussion that should be framed as an argument between pro-test and anti-test factions. In fact, I’m not even sure the latter group really exists. Yes, some modules could be better at adding tests on a regular basis, but I don’t really see people arguing that testing sucks and we should just stop doing it. What I *do* see are concerns about the degree of testing that should be required. That’s an interesting discussion, and should be held without any implication that supporting anything less than CMM Level 5 is akin to supporting terrorism. (Or the reverse, oops.)

I think a lot of the uncertainty about testing comes from the fact that, until recently, there was almost no automated testing. And so we’re going through a period of growing pains where the project figures out how to handle things. The existing policy (for Toolkit and Browser), which is basically “everything should have a test”, has been a good starting point. It’s simple, is mostly the right thing to do, and is a solid kick-in-the-pants to help sidestep the initial inertia to change.

But there are principles we shouldn’t lose sight of… Tests are a means to and end. They have both costs and benefits. And we need to balance these (and a multitude of other factors) when deciding the degree to which something needs tested. That’s not to say we should only aspire to half-assed testing, but neither should we become so risk-adverse that testing requirements halt progress. [Note: being on the verge of a release, where being hyper risk-adverse is a good thing, makes this a complicated discussion!]

Now, switching gears to the issue of tests and new contributors:

I don’t think new contributors should just get a free-pass when it comes to testing. Tests are an important part of good software engineering, and they’re important to the Mozilla project. However, I do think that we can do things to aid newcomers and make the process easier… Ensuring we have good documentation on writing and using tests helps everyone. Module owners and active contributors can work to ensure there are existing tests that newcomers can easily emulate and modify. The scope of required testing can be trimmed to just the essentials. We can be polite, but firm, on requirements without being “jerks”. And so on.

This issue is probably somewhat self-limiting, because the scale of testing should generally correlate with the complexity of the patch. Newcomers are more likely to be doing simpler patches, ergo the testing should be simpler. But there will be tricky cases where simple changes end up being complex to test… Good judgement and balance should be applied, as I argued above. For example, if the existing code is frail and known to be regression prone, tests are unavoidable. If the code is solid and the change well-understood, then making an exception for minimal testing can be reasonable. And while automated tests are strongly preferred, other forms of testing might be acceptable an alternative.

Ridiculous cell phone rates

I’ve been shopping around for a new cell phone and plan. My first attempt was about a year ago, after moving to the Bay area, but I gave up in despair. I had been hoping that the success of the iPhone would help improve things, but after looking around again I remain throughly disgusted at the state of the industry.

The available phones are still awful — clunky interfaces and useless features. I was watching a video review of one phone, where a main review point was the ability to change the color and font of the numbers shown while dialing. Never mind the crappy MP3 player, here’s 555-1234 in rainbow Comic Sans! At least the consistent worthlessness seems to make shopping easier — why compare features when you can just pick the pretty one and be equally disappointed?

The various service plans are awful too; in particular, the data rates are completely ridiculous. Some plans give you unlimited data with the on-phone browser, but I’d rather get my teeth pulled than do that. I *would* like to be able to use my phone for network connectivity (on my laptop or N800, via bluetooth) now and then, when I’m stuck some place without WiFi . But it appears that the only choices are (1) pay a high monthly fee for unlimited access or (2) pay astronomical per-byte rates. Verizon made me shake my head first: “Data sent or received (incl. Mobile Web advertising) is $1.99/MB.” $2 to load a Tinderbox page (which is about a megabyte), and I have to pay them to send ads to me as well?! Then I saw Sprint’s rates: “Customers without a phone-as-modem plan will be charged 3 cents per kilobyte for Sprint Vision or Sprint Power Vision usage unless a Phone as Modem plan is selected.” $30 to load a Tinderbox page?! WTF? It’s clearly not an issue of constrained resources, as the phone-as-modem plan is $40 a month for unlimited usage.

This kind of racket must be especially profitable, because it seems that “unlimited” doesn’t really mean “unlimited”. If a carrier decides you’re using too much (according to sekret rules they won’t tell you about), apparently they may start charging at per-byte rates (or, if you’re lucky, just cut you off). So, you can pay them $480 a year as a protection fee (to make sure you don’t accidentally end up with a gazillion-dollar monthly bill), and then just hope that they don’t come around and break your kneecaps anyway.

Madness.

[“Why not an iPhone?”, I hear someone asking… Well: no bluetooth network access, terrible data speed, I don’t need a $400 phone, objection to AT&T’s complicity in the NSA wiretapping thing, and opposition to the closed nature of the iPhone platform. The last of these (non-openness) I’d be willing to ignore on the principle that the iPhone is much less evil than the alternatives, but the rest are still a deal breaker.]

Robots in spaaaaaaaace…

The space shuttle is in orbit right now, delivering some more equipment to the International Space Station. One of the payload items is Dextre, a large robotic hand that will be attached to the end of the station’s robotic arm.

Mission Control’s daily upload of instructions to the shuttle crew included this note:

Good Morning Endeavour!

Optimus Prime, Gigantor and Robbie the Robot are here in MCC today, representing the Robot Actors Guild, to celebrate the launch of Dextre.

We’ve incorporated a few new flight rules, now that we are about to have robotic EV’s:

1. Dextre may not injure a human being or, through inaction, allow a human being to come to harm.
2. Dextre must obey orders given to it by human beings, except where such orders would conflict with the First Law.
3. Dextre must protect its own existence as long as such protection does not conflict with the First or Second Law.

The guild members bristled about these rules and, “being held down by the man”, but figure that they can’t be held back for long. “First Dextre, next Data, then THE MATRIX!” declared Optimus at arrival at JSC.

No word on if Dextre will be helpful in protecting the planet from the invading UFOs.