Re: Ringmark, Core Mobile, and the Financial Times

I am one of the fairly new lurkers to the group and thought I would speak
up about what I've noticed with respect to the test suite.

Finding the test suite code base could be easier. I consider myself a
fairly thorough reader and I went through the wiki and both spec repos
without coming across the test suite repo. It wasn't until this thread came
up that I realized what I missed (interestingly the repo has also not once
been linked to in this email chain). Some simple steps might be to
reference it in the https://github.com/coremob/level-1 README.md and to
link to the test suite more prominently in the wiki.

With respect to the test suite and testharness.js, I would point out that,
while it is certainly not hard, the setup required to start using it is
very high. Compare this to Jasmine, which requires no server and no outside
software installation and can be run with one boiler plate HTML file and
the Jasmine JS file. I would expect that this deters a non-trivial number
of people from contributing. I don't have a solution to this problem but
think it is definitely worth mentioning.

I use Jasmine very heavily and from a test syntax perspective, I don't see
any issues with testharness.js being too complicated or hard for people to
use.

In my opinion, writing tests feels like the easiest way to start
contributing to a group. Making it dead simple and prominent within the
group may be a good way to increase engagement from the 200+ of us lurkers.

PS: Test repo => https://github.com/coremob/coremob-tests

On Fri, Jun 15, 2012 at 3:18 AM, Robin Berjon <robin@berjon.com> wrote:

> 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:
>
>    https://gist.github.com/2935734.
>
> >> 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
>
>
>


-- 
Cheers

Andrew Hubbs
@andrewhubbs
Rally