W3C home > Mailing lists > Public > public-test-infra@w3.org > July to September 2012

Re: W3C Testing How To slides

From: James Graham <jgraham@opera.com>
Date: Mon, 17 Sep 2012 21:05:49 +0200 (CEST)
To: Philippe Le Hegaret <plh@w3.org>
cc: public-test-infra <public-test-infra@w3.org>
Message-ID: <alpine.DEB.2.02.1209172044160.20626@sirius>
On Sun, 16 Sep 2012, Philippe Le Hegaret wrote:

> Mike and I put slides together on how to do testing at W3C:
> http://w3c.github.com/testing-how-to/

Nice :)

A few points below:

== Technical feedback ==

assert_true(!!MyE.firstElementChild); is an abuse of assert_true; that's 
why it looks so ugly :) If you wanted to write a real test here you would 
use assert_idl_attribute(MyE, "firstChild"); But that would likely fail in 
some browsers due to them having the IDL attributes in the wrong part of 
the prototype chain. I suggest that it would be clearer to think of a 
different test here. For example a test like assert_equals(document.title, 
"the title element value") or similar would be quite straightforward.

The paragraph explaining the test is unnecessary and slightly harmful 
(it's better to write *more* tests than to write long descriptions in each 
test). It also doesn't scale to > 1 test per page. Descriptive test titles 
are more important (and using <title></title> to describe the whole file).

The async test should be something that is actually async. For example you 
could test that the load event fires:

var t = async_test("Load event fires");
onload = function(e) {
   t.step(function() {
     assert_equals(e.type, "load");
     t.done();
   });
}

This would then be usful to demonstrate how t.step_func(); can reduce 
boilerplate for this type of test.

The demo for the manual test doesn't seem to work very well. It might fail 
in the browser that I'm testing, but that wasn't at all clear from the 
text. It would be nice to find an example that has a clearer pass/fail 
condition.

Many more test types will need client and server side code than just 
XHR/WebSockets. For example with HTML5 navigation it's hard to write some 
of the tests without precise control over the timing of various loads. So 
I expect requiring at least a subset of tests to have a server side 
component to be the common case.

The github repos are read-only at the moment afaik.

We should change the submitted/approved structure in the repos :)

== General Feedback ==

I agree with Tobie that these slides have rather a large amount of text; 
more than I would like as an audience member. It could be good to trim 
down the bits to be projected and put the other material into an adjunct 
page that could be used as a virtual handout.


> This slides set is intended to serve as an introduction and could be
> used to present testing to Working Groups.
>
> I'm thinking to do a break out session during the TPAC by going over
> those slides.

That sounds like a great idea.
Received on Monday, 17 September 2012 19:06:20 UTC

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