W3C home > Mailing lists > Public > public-html-testsuite@w3.org > October 2012

DOM 2 HTML tests

From: Ms2ger <ms2ger@gmail.com>
Date: Sun, 28 Oct 2012 16:07:52 +0100
Message-ID: <508D4A48.4060609@gmail.com>
To: "public-html-testsuite@w3.org" <public-html-testsuite@w3.org>
Hi all,

I noticed that Philippe has recently been adding DOM 2 HTML tests to the 
repository. I don't believe that is a good idea.

In the first place, the code is quite unreadable, being generated from 
XML files that catered to Java. For example, a test would look like

on_event(window, "load", domtest.step_func(function (dom_event) {
     var nodeList;
       var tbodiesnodeList;
       var testNode;
       var bodyNode;
       var newRow;
       var rowsnodeList;
       var vsection1;
       var vsection2;
       var vrows;
       var doc;
       doc = window.document;
       nodeList = doc.getElementsByTagName("table");
       assert_equals(nodeList.length,3);
testNode = nodeList.item(1);
       tbodiesnodeList = testNode.tBodies;

       bodyNode = tbodiesnodeList.item(0);
       rowsnodeList = bodyNode.rows;

       vrows = rowsnodeList.length;

       assert_equals(vrows,2);
        newRow = testNode.insertRow(-1);
       tbodiesnodeList = testNode.tBodies;

       bodyNode = tbodiesnodeList.item(0);
       rowsnodeList = bodyNode.rows;

       vrows = rowsnodeList.length;

       assert_equals(vrows,3);

     domtest.done();
}));

with random indentation, and a large number of useless local variables 
that cloud the intention of the test.

Second, these tests barely touch the surface of what needs to be tested; 
in this example, three assertions are made, of which one only checks 
that the test file has the three tables that it expects. (Just one of 
these tables is actually used in the test, of course.) No assertions are 
made about the return value of the insertRow call, or what the nodelist 
or DOM tree actually looks like. Introducing such tests is at most 
useful for window-dressing and poorly thought out interoperability 
claims, but not for conformance testing of the level I expect from this 
group.

Third, they rely on such beautiful helper functions as

function assert_instance_of(type, obj) {
     if(type == "Attr") {
         assert_equals(2,obj.nodeType);
         var specd = obj.specified;
     }
}

and assert_equals_list (which reimplements assert_array_equals, poorly). 
I think we can all agree that such functions do far more harm than good.

Fourth, the tests were written for specifications that we've known for 
almost a decade to be badly written, ambiguous and not web-compatible. 
In the example above, incorrect assumptions are made about where the new 
row will end up in the DOM tree, and (at least) Gecko fails the test 
because it implements the specification we're supposed to be testing.

For all those reasons, I propose to remove this set of tests from the 
repository, and focus our time on writing tests that are actually useful 
and correct.

Thanks
Ms2ger
Received on Sunday, 28 October 2012 15:08:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 28 October 2012 15:08:22 GMT