Published: Tuesday, Jun 30, 2009 Last modified: Monday, Apr 8, 2024

In order for a “Working Draft” specification to become a “Candidate Recommendation” at the W3C, it is likely to need a test suite.

Since the Widget P&C specification is of profound interest to many, we hope you too will be interested in helping realise its potential. A Widget test suite would help ensure compliant and interoperable Widget runtimes(WRTs).

Grab the W3C widget test sources with CVS

cvs login

Password is ‘anonymous’.

cvs checkout 2006/waf/
cd 2006/waf/widgets/tests/test-cases/

Subsequent updates to the checkout can be done with cvs update -d

Bookmark these docs

Tip for vim users:

au BufReadCmd *.wgt call zip#Browse(expand("<amatch>"))

How the tests for the test assertions are tracked

The Widgets 1.0: Test Suite for Packaging and Configuration has some Javascript which extracts the test assertions from;%20charset=utf-8.

Every testable assertion (TA) has a unique id, so ultimately it gets “mashed up” with a test-suite.xml, which will have entries like:

<test for="ta-dxzVDWpaWg" src="test-suite/ta-dxzVDWpaWg/000/test.wgt">
Test to make sure that the the UA only checks the root of the widget for config files, and not in an arbritrary folder.
To pass, the user agent must result treat this widget as an invalid widget (config file is not at the root).

What is ta-dxzVDWpaWg again? You can check the test assertion by either:

xmlstarlet should be packaged in your Linux distribution. Here is another tip.

How are these widgets generated from test sources?

  1. or the CVS interface
  3. or the CVS interface
  4. And some W3C CVS blood, sweat & tears

WTF !! I’m an implementor and every Widget test FAILS!

Does your WRT accept widgets without the optional widget id attribute?