DOM 1 Test Problems

Well, I downloaded the XML and DOM specs and built me an XML parser and 
DOM implementation.
Then I found the DOM TS and hooked it up so it would test my 
implementation from JsUnit.
That's when I ran into a few issues.

First, the nodeprocessinginstructionsetnodevalue test, sets the 
WillBeModified flag wrong so later the processinginstructiongetdata test 
fails.

Second, JsUnit requires that null be retrurned from nodeValue in several 
cases.  However, if we concider ECMA script with DOMString mapped to 
ECMA's string type, then we are requiring that an attribute of DOMString 
type will produce a value that is not a DOMString !!!!  While that may 
be acceptable, the DOM spec says nothing about nodeValue producing a 
value that is not a DOMString.  In fact it never says anything about 
null being different from an empty string.  There needs to be support on 
the ECMA side of the house to support an implementations that conciders 
ECMA's null to NOT be a DOMString.  In such an implementation, a null 
DOMString is the same thing as an empty string.  ECMA null's will never 
be passed as a DOMString.  When one conciders that DOMString has been 
made a value type in later DOM versions and the additional overhead of 
having to continually look for ECMA null's passed as DOMStrings, there 
is a strong case for an  implementation that does not allow ECMA null's 
to be passed as DOMStrings.

This issue affects the AssertNull function, which can be fixed with a: 
aVar===null || aVar==='"" test instead of the aVar===null test that 
currently exists.  It also affects the hasFeature tests.  In this case 
the domimplementationfeaturenull test will fail but the 
domimplementationfeaturenoversion test will work.  However with this 
implementation they are the same test.  So there needs to be a way to 
turn off (or make it pass) the domimplementationfeaturenull test. 
 Another test that is affected is testparseintolistofelements.  This one 
uses a comparison to null that also fails.

Another issue is the the raising of NO_MODIFICATION_ALLOWED_ERR when the 
nodeValue attribute is set on Entity, Entity Reference, Document Type 
and Notation nodes.  Yes the DOM spec says these operations have no 
effect.  But it also says that they should raise 
NO_MODIFICATION_ALLOWED_ERR when the node is readonly.  Since these four 
node types are readonly by definition, one would expect the tests to be 
looking for NO_MODIFICATION_ALLOWED_ERR.  However they don't,  they just 
check that value is unchanged.

A concideration is that the elementremoveattribute and 
elementattributerestoredefaultvalue both test the same attribute 
("street").  It would be better if the elementremoveattribute test 
worked on an attribute that did not have a default attribute.  At least 
then the tests would be testing different things.

A test of passing a DocumentFragment node to the replaceChild operation 
would also be nice.

All in all the test suite is quite nice, but now that I have my 
implementation passing all the tests, I NEED MORE TESTS !!!  When will 
the DOM Level 2 tests be completed ???   For that matter, why are the 
tests not generated ???

Given the simple (and I mean SIMPLE) structure that the DOM defines, why 
aren't, at least a large portion, of the simple test cases  generated 
from the specification ????   It sure would not be difficult to write a 
routine to generate things like 'Attempt to add every node type as a 
child to every other node type', or 'Create all possible legal node 
structures from 1 to N levels deep, clone them and compare the clones 
for equivelence', or 'Generate all possible modification sequences for a 
set of 1 to N attributes on a single element',  or 'Generate sequences 
of legal and illegal names and attempt to create nodes using the names', 
 or 'Generate tests for all the possible document mismatch errors', etc. 
etc,  etc.

Only 290 tests ?????  That was easy ......

Joe Schafer
jschafer@iquest.net

Received on Monday, 27 May 2002 14:33:15 UTC