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
export CVSROOT=:pserver:firstname.lastname@example.org:/sources/public 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
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). </test>
What is ta-dxzVDWpaWg again? You can check the test assertion by either:
- Finding the string
ta-dxzVDWpaWgin Widgets 1.0: Test Suite for Packaging and Configuration
- Or by appending it to the Widget packaging specification like so http://dev.w3.org/2006/waf/widgets/Overview_TSE.html#ta-dxzVDWpaWg
wget -q http://dev.w3.org/2006/waf/widgets/tests/test-suite.xml -O /dev/stdout | xmlstarlet sel -t -c "//test[@for='ta-dxzVDWpaWg']" -v '@src'
How are these widgets generated from test sources?
- http://dev.w3.org/2006/waf/widgets/tests/test-cases/ or the CVS interface
- http://dev.w3.org/2006/waf/widgets/tests/test-suite/ or the CVS interface
- 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?