W3C home > Mailing lists > Public > public-html-testsuite@w3.org > May 2010

RE: Test Case Approval Request

From: Kris Krueger <krisk@microsoft.com>
Date: Tue, 4 May 2010 04:38:24 +0000
To: Kris Krueger <krisk@microsoft.com>, James Graham <jgraham@opera.com>, "Anne van Kesteren" <annevk@opera.com>, "phl@w3.org" <phl@w3.org>
CC: "public-html-testsuite@w3.org" <public-html-testsuite@w3.org>
Message-ID: <FA9085650D2F8B4A9D501ED9D9706E9A0BF9B6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Attached is an update to the test case that I'd like to see approved.
If you want to run this test for interoperability then Remove the '.txt' and place domtestcase.js at ../common.

 * Change title/description, from interface to attribute ( annevk@opera.com feedback)
 * Change doctype to html5 (tross@microsoft.com feedback)
 * Enable more tests via code resuse, e.g. be more data driven and run test in a loop (annevk@opera.com feedback)
 * Update to use strict equality for assertEquals (jgraham@opera.com)
 * Create common folder to hold domtestcase.js (krisk@microsoft.com feedback) 

If you don't agree now is the time to speak up, in the list or at the conf call in the morning.

Sorry for not just sending a pointer to HG - 
The reason is that  HG appears to have an issue, I attempted a few times to 'push' a change with the feedback.
Maybe Philippe can take a peek - the error I see from my freebsd client is below when I 'push.

permission denied: .hg/store/lock


-----Original Message-----
From: public-html-testsuite-request@w3.org [mailto:public-html-testsuite-request@w3.org] On Behalf Of Kris Krueger
Sent: Tuesday, April 20, 2010 7:34 AM
To: James Graham; Anne van Kesteren
Cc: public-html-testsuite@w3.org
Subject: RE: Test Case Approval Request

Given the size of the HTML5 spec, I would hope that many people contribute tests to the suite.
For the DOM tests that get submitted, I'd suggest the following as potential requirements.

* Simple Run (Just Load The Page)
* Pass/Fail Results are clear and consistent
* All the core parts (not tests live in a single js file, e.g. asserts)
* No complex design - hidden iframes, page load events, etc..


-----Original Message-----
From: James Graham [mailto:jgraham@opera.com]
Sent: Tuesday, April 20, 2010 1:39 AM
To: Anne van Kesteren
Cc: Kris Krueger; public-html-testsuite@w3.org
Subject: Re: Test Case Approval Request

On 04/20/2010 08:24 AM, Anne van Kesteren wrote:
> On Tue, 20 Apr 2010 15:20:18 +0900, Kris Krueger <krisk@microsoft.com>
> wrote:
>> Just to make sure I understand your feedback...
>> You think that the test is valid and can help overall browser 
>> interoperability looking at past browser implementations.
>> Though the title of the test needs to be more clear, call out that 
>> it's a content attribute test rather than an interface test.
> Yeah, though it would probably be simpler to have a single test for 
> all known content attributes on all known elements. You would then 
> simply test with a few values on all of these (e.g. colors, URLs, 
> space-separated items, simple tokens, etc.) and test whether they get 
> normalized in some way. Should be quite simple to do with a few arrays 
> and a loop.

Just as a matter of clarity, is the expectation that Microsoft will write a large number of tests using this framework and submit them? Or is the expectation that this will be the preferred framework for DOM test submissions from multiple parties? If the latter, I think it would be worthwhile to spend a few cycles iterating requirements / designs for testing DOM functionality. If it is the former then I think you are free to use whatever design you prefer (subject to it being easy to integrate with browser regression systems).

In either case it seems that there are a few potentially significant edge-case bugs in the current harness e.g. it fails to use strict equality for assertEquals and it doesn't cope well with NaN.

Received on Tuesday, 4 May 2010 04:39:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:35 UTC