W3C home > Mailing lists > Public > public-coremob@w3.org > June 2012

Re: Ringmark, Core Mobile, and the Financial Times

From: Robin Berjon <robin@berjon.com>
Date: Fri, 15 Jun 2012 12:18:12 +0200
Cc: W3C CoreMob CG <public-coremob@w3.org>
Message-Id: <1D795432-10F6-42F2-8143-819BA804D41E@berjon.com>
To: James Graham <jgraham@opera.com>
Hi James,

On Jun 15, 2012, at 10:24 , James Graham wrote:
> On 06/13/2012 11:35 AM, Robin Berjon wrote:
>> Is testharness.js considered hard? My personal experience is that
>> that may be true but not its fault. If you've used another testing
>> framework such as Jasmine or Mocha before, I reckon it ought to be
>> reasonably easy to pick it up. The syntax differs but the concepts
>> are all pretty much the same.
> I think one difference is that testharness.js is explicitly designed to be primitive in certain respects; for example it doesn't try to invent its own abstractions for writing async tests in the same way as say qunit or mocha, but expects you to use the browser event loop directly. This is pretty essential when it is details of the event loop that you are trying to test, but is maybe surprising for people who are used to working with higher-abstraction libraries.

I'm not sure what you mean here so I've put up a very simple gist that compares async testing in testharness.js, Jasmine, QUnit, and Mocha. I was too lazy to actually set these up properly and I'm mostly working from memory so it's entirely possible that there are glaring issues with the code (or that I've mixed two frameworks up — they're all so similar they just tend to blur…). You can look it up, comment, scream, patch, etc. at:


>> There isn't much we can do about that — it's not as if there weren't
>> already loads of testing advocacy going on. Perhaps the only thing
>> that can make testharness.js easier on people would be better docs?
>> Perhaps something along the lines of what the Jasmine folks recently
>> did: http://pivotal.github.com/jasmine/. Not only is it a good
>> tutorial, it's also runnable.
> "Better docs" is hard to say no to :) And it would of course be nice to have a website for testing that looks like it was designed sometime this decade to give the impression that W3C testing isn't some unapproachable academic discipline but is warm and fuzzy and modern.

Yeah, the experimental revisit of the testing framework looks (very unoriginally) more recent: http://w3c-test.org/framework/app (note that the DB is currently down though, so it's not at all functional :).

> I can help with the former of course, but am totally the wrong person to do the latter.

I'll start putting together some form of tutorial for TH.

>> I think that making the Test Tzar for a spec right up there with the
>> Editor ought to be a requirement in all specs. "Test Contributors"
>> sounds secondary though. If you can find me a good name for it, I'll
>> add support for it to ReSpec post-haste. Conformance Lead? It should
>> be something that can shine on a CV.
> WebApps has a notion of "test facilitator" (not the most glamorous title, perhaps). Listing that person on the spec doesn't seem like a bad idea.

Yes, we definitely should list that person — but while this may seem trivial I think that it should be under a title that looks good on a résumé so that it gives an incentive to put the work in. "Test facilitator" sounds like you were given a title out of pity.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Friday, 15 June 2012 10:18:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:47 UTC