Re: testing plans for Web IDL

Hi,

Thank you so much for mentioning esidl, Dom.

Last month we have also released a new JavaScript bridge to our Web
IDL C++ binding using JSAPI [0] so that we can use TraceMonkey. A
couple of trivial test programs using JSAPI are at,

  http://code.google.com/p/es-operating-system/source/browse/trunk/esidl/jsapi/test/

'bridge.test.cpp' verifies Web IDL's unique features like stringifier,
deleter, overloaded operations, etc., can be exposed to JavaScript
over JSAPI with generated C++ source files from 'test.idl'.

'dom.test.cpp' constructs JavaScript prototype chains from core Web
IDL definitions, and it could be extended to run more tests written in
JavaScript. Since not every W3C specification has been switching over
to Web IDL yet, we're using semi-custom Web IDL files [1], mainly
derived from Cameron's works [2]. This is a kind of chicken-and-egg
problem we're hoping to get it fixed soon. :)

Anyway, it might be interesting if we can run the same JavaScript
tests on Travis's work [3], ours, and maybe others, and then compare
the results. As we're not going for mixin prototype objects, I guess
things are now more simplified.

[0] https://developer.mozilla.org/en/JSAPI_Reference
[1] http://code.google.com/p/es-operating-system/source/browse/trunk/esidl/dom
[2] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0022.html
[3] http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/0009.html

Best,

 - Shiki Okasaka


2011/5/25 Dominique Hazael-Massieux <dom@w3.org>:
> Hi,
>
> I read with great pleasure that there is now a well-defined schedule for
> moving Web IDL to LC: good job!
> http://www.w3.org/mid/4DDC2483.6030401@nokia.com
>
> Has there been any thoughts given around the CR phrase for Web IDL?
> Given how important that specification is, I'm hoping there will be a
> good test suite to back it up.
>
> Are there plans to build such a test suite?
>
> A test suite would need to show that the ECMAscript bindings [1] of Web
> IDL fragments actually follow the various constraints and algorithms
> that the spec defines.
>
> Ideally, the said Web IDL fragments would come (or be inspired) from
> APIs that are already well-deployed; I'm not sure if we have enough such
> APIs to cover all the features of Web IDL (but if we don't, maybe the
> features that don't match that requirement should be marked at risk /
> moved to v2?).
>
> Even more ideally, in the process of building that test suite, we would
> build a tool that can generate tests to verify the correct
> implementation of the Web IDL fragment in a given browser. There is
> already at least one tool that does this [2], but it doesn't match the
> latest evolution of Web IDL (and is also probably too limited as is to
> be sufficient toward that).
>
> FWIW, a few pointers to existing Web IDL processors with their test
> suite (but which mostly address proper syntactic parsing):
> * widlproc , a tool that turns Web IDL fragments into XML (and which I
> now maintain) http://widl.webvm.net/
> http://widl.webvm.net/svn/widlproc/trunk/test/valid/idl/
>
> * esidl , a tool that generates C++ stubs from Web IDL fragments
> http://code.google.com/p/es-operating-system/source/browse/
> http://code.google.com/p/es-operating-system/source/browse/#svn%2Ftrunk%
> 2Fesidl%2Ftestsuite
>
> * Whatpm::WebIDL a tool that parses Web IDL fragments and turns them
> into Perl objects (used by [2] to generate test cases)
> http://suika.fam.cx/www/markup/html/whatpm/Whatpm/WebIDL.html
> http://suika.fam.cx/gate/cvs/markup/html/whatpm/Whatpm/WebIDL.pm
> http://suika.fam.cx/gate/cvs/markup/html/whatpm/t/webidl/
>
> Dom
>
> 1. I pretty much think the Java binding should be moved out of the main
> spec into a Note; it seems to me very unlikely that anyone will spend
> the necessary effort to ensure that the Java bindings are correct in the
> timeframe we want for Web IDL progression.
>
> 2. http://suika.fam.cx/www/webidl2tests/readme
>
>
>
>

Received on Thursday, 26 May 2011 04:13:31 UTC