Re: Updated test-to-java, etc

Comments inlined.

--Mary
  ----- Original Message ----- 
  From: Curt Arnold 
  To: www-dom-ts@w3.org 
  Sent: Thursday, October 25, 2001 5:33 AM
  Subject: Updated test-to-java, etc


  The problem with firstChild was due to firstChild being both a method (of TreeWalker) and an attribute (of Node), the transform didn't like that too much.  I've also cleaned up indenting and a long term problem with the spurious /* undefined */ comments.  Have not made the corresponding changes to test-to-ecmascript.xsl

  [mb] Okay -- will give it a try.

  I removed the setNodeValue() tests that I recently added to some of the documentCreate* tests and created distinct tests (nullnodevalue01-09) that create or access each of the node types that have nodeValue permanently set to null.

  [mb] Good idea.  I think in general you want to make the tests as atomic as possible.

  staffNS.xml was not present, so most all the test fail.

  [mb] Should be there now.

  Several of the tests create a list of responses to unrelated evaluations, append the results of the evaluations to a list and then compare the lists.  That is undesirable since it unnecessarily complicates the tests.  List comparisons should only be used when there is an iteration involved.  Most of these look like they are badly formulated anyway.

  [mb] Would be more informative if you actually identified the tests.  The tests have been written by a couple of different folks, and then 
  translated into XML, primarily by a guest researcher who is no longer with us.  On our side, we have to track from original source, through 
  the translation to XML, and then the test suite translation.  This is much easier if you can identify which tests you are having problems with in 
  addition to the actual problem (problem definition above is okay, but which tests?)

  isSupported12 looks pretty weird, it appears to be testing if the parser under test supports all know DOM modules (Core, Events, HTML) and both level 1 and level 3!!!!.  No parser in existance would pass this test.  I did rewrite it to eliminate the nested <foreach> since I haven't supported nested <foreach> in the code generation.

  [mb] I agree that level 3 should not be tested, but I would suspect level 1 and 2 should be supported.  We went back and forth with this type of test.  One 
  method would be to break it out into different combinations, supporting the atomic method of testing.  Any thoughts on whether multiple assertions 
  within a test would be better than many tests, where different combinations are tested.  

  Several tests had unnecessary while statements and were depending on <plus> to do string concatenation.  I simplified these by adding the concatentated string to the literals in the array members and removing the whiles.

  [mb] I'm not finding any documentation trails indicating what you changed and what you didn't.  I thought we agreed early on that e-mail was not 
  the way to track this type of info.  Isn't there a metadata tag available for modified by?  Or, perhaps better documentation when the files are committed 
  to CVS -- the one comment applied to all files isn't very informative, and with so much going on, it's difficult to follow the e-mail trail.

  All the tests seemed to have spurious line feeds which I have cleaned up.

  All committed to the CVS.