- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 11 Sep 2012 14:15:38 +0200
- To: public-html-testsuite@w3.org, "Thiago Marcos P. Santos" <thiago.santos@intel.com>
- Cc: "Carr, Wayne" <wayne.carr@intel.com>, "Zhiqiang Zhang" <zhiqiang.zhang@intel.com>
On Tue, 11 Sep 2012 12:47:59 +0200, Thiago Marcos P. Santos
<thiago.santos@intel.com> wrote:
> Hello,
>
> I would like to submit the following tests:
> http://dvcs.w3.org/hg/html/rev/dcbfd1474a19
>
> We are verifying the conformance with the following specs:
> http://dev.w3.org/html5/spec/single-page.html#dom-media-controls
> http://dev.w3.org/html5/spec/single-page.html#dom-media-defaultmuted
> http://dev.w3.org/html5/spec/single-page.html#dom-media-loop
> http://dev.w3.org/html5/spec/single-page.html#dom-media-muted
> http://dev.w3.org/html5/spec/single-page.html#dom-media-volume
> http://dev.w3.org/html5/spec/single-page.html#dom-dim-height
> http://dev.w3.org/html5/spec/single-page.html#dom-dim-width
>
> Review is appreciated and Zhiqiang Zhang will address any feedback.
I don't have time to do a proper review right now, but I noticed that the
general pattern of having the bulk of the testsuite in a single js file
and then calling one function in the test itself, like:
2.19 + <script type="text/javascript">
2.20 + controls_attribute_type();
2.21 + </script>
...makes it hard for the person reading the test to follow what it's
doing. Generally it is recommended to put it inline in the test itself.
It seems the tests have more focus on describing what each test does and
having boilerplate and links and everything than to make sure all aspects
of a feature are covered (like error handling, edge cases, testing how
multiple features interact). Bugs are more commonly found in the latter
category, so tests that have that kind of coverage is more useful for the
purpose of highlighting implementation bugs than tests that only check
that shallow usage works.
cheers
--
Simon Pieters
Opera Software
Received on Tuesday, 11 September 2012 12:16:14 UTC