Re: Some feedback on the DOM level 1 core tests

Some feedback on the DOM level 1 core testsFreek de Bruijn wrote:

>Would it be a good idea to combine multiple tests into one class, instead
of using a
> separate class for each test? This would reduce the huge number of classes
that are
> generated at the moment, making the test suite more manageable and
improving
> performance as well. The original NIST test suite has 15 classes
> (one for each interface), which is a lot easier than the 250+ classes we
have now.

I think that we want to maintain the definition of one test == one XML
document since that gives us a revision history of each test instead of a
revision history of all tests for a particular interface.  In addition,
hopefully we will have tests from different sources and trying to have
different authors working in the same file is just not a pleasant thing.

The one test == one Java file/class flows out of that since it is most
natural to do a case by case conversion using XSLT.  If it class bloat is
really a significant issue, we could address it.  But I can't see
performance being a crucial factor in running the suite as long as a run is
less than a few seconds.

>In tests characterdataappenddatanomodificationallowederr.xml,
>characterdatadeletedatanomodificationallowederr.xml,
>characterdatainsertdatanomodificationallowederr.xml, and
>characterdatareplacedatanomodificationallowederr.xml the tagname in the
following statement >should probably be "gender":

Did a global change of "geneder" to "gender"

>For tests characterdataappenddatanomodificationallowederr.xml,
>characterdatadeletedatanomodificationallowederr.xml,
>characterdatainsertdatanomodificationallowederr.xml,
>characterdatareplacedatanomodificationallowederr.xml, and
>characterdatasetdatanomodificationallowederr.xml the comment tells that the
third gender >element should contain an entity reference, but this is not
the case in the older version of the >staff.xml document.

I held off on this one till we can get a clarification about the resource
files from NIST.

>In documentcreateentityreferenceknown.xml, the type of newEntRefNode should
probably be >EntityReference (instead of Element):

Changed

>Several tests seem to test equivalence of two lists where one list contains
a String and the other >contains an Integer. Some tests also try to assert
null values of nodes with a String value of >"null" in a list, maybe it's
better to use assertNull. Since I don't have access to the cvs server
>(but who has ;-), could somebody fix these issues?

Changed those you mentioned plus one more (nodeclonenodefalse).

I did take some editoral liberty with documentcreateprocessinginstruction.
There was a discussion on the www-dom-ts mailing list much earlier
http://lists.w3.org/Archives/Public/www-dom-ts/2001Apr/0020.html about the
inappropriateness of testing createProcessingInstruction with a target
("XML") that is an illegal value per the XML spec.  I have changed the
target to an innocuous value "TESTPI".

Most DOM implementations will create a PI with an "XML" target, but MSXML
will reasonably raise an exception.  Joe Kesselman's suggestion
(http://lists.w3.org/Archives/Public/www-dom-ts/2001Apr/0020.html ) was to
change the target and but not to add a negative test for an "XML" target
until the Level 3 effort where the appropriate behavior will be prescribed.

Received on Tuesday, 21 August 2001 12:32:42 UTC