Re: Status check

Robert Clary wrote:
> 
> 
> Ok. I will put together an example and post it so we can use it as a 
> straw man for discussion.
> 
> Bob
> 
> 

Straw man is available at <http://bclary.com/dom-ts/tests/>.

Run <http://bclary.com/dom-ts/tests/dotests.html> to see it in action.

I rewrote most of DOMTestCase.js 
<http://bclary.com/dom-ts/tests/DOMTestCase.js> as it pertains to the 
builder and factory.

It had much special casing of code and assumed too much knowledge of 
particular parsers' implementation capabilities. I believe the approach 
I used will be more maintainable and allow more access to the tests by 
alternative browsers. I also removed the document caching since I 
believe that is incompatible with the asynchronous document loading.

Note that xbDebug is used to generate warning messages depending upon 
your choice of implementation, choice of implementation attributes and 
the choice of test which I believe will be helpful in explaining the 
results of the tests.  To see copious debug messages, click the xbDebug 
check box on the dotests.html page. Note that xbDEBUG can be used to 
selectively send messages even if the global debugging flag is turned off.

I am sure there are aspects of the original DOMTestCase.js that I did 
not fully appreciate so please take this as a starting point and not the 
final version.

Example Tests
-------------
The modifications to the javascript of the test cases turns out to be 
pretty minimal.

<http://bclary.com/dom-ts/tests/attrdefaultvalue.html>
<http://bclary.com/dom-ts/tests/attreffectivevalue.html>
<http://bclary.com/dom-ts/tests/elementwrongdocumenterr.html>
<http://bclary.com/dom-ts/tests/hc_attrname.html>
<http://bclary.com/dom-ts/tests/nodeappendchild.html>

Changes required:

external script jsUnitCore.js included.

javascript moved from HEAD to BODY to allow use of document.write to 
generate IFRAMEs/EMBED tags for data document loading.

call to domtsParserManager.addFile for each data document to be loaded

use of exposeTestFunctionNames() to tell jsUnit what the test function 
name is.

Note that I placed a call to xbDEBUG.dump inside the test function to 
catch exceptions thrown when the test object was created. I believe this 
is useful for diagnostic purposes and should be retained. I believe that 
additional use of xbDEBUG.dump inside of tests as well as the document 
loaders will be useful however I left that for another time.

I am not entirely certain I am handling the Adobe SVG plugin properly so 
that may require additional work. In particular, the Adobe SVG plugin 
loader only works in Internet Explorer at the moment but since the Adobe 
SVG plugin does not currently support Mozilla that is not too much of an 
issue. This may have to be revisited at some point however.

*** Due to the nature of the DOMTSParserManager, it was necessary to 
make sure that each data document loaded has a unique name. I duplicated 
staff.xml and staff.svg to staff2.xml and staff2.svg for use in the 
elementwrongdocumenterr test. I don't think this is a major issue 
however if you care to extend DOMTSParserManager so it can handle 
multiple instances of files with identical names, please feel free to do 
so. :-) ***

Example Suite
-------------
<http://bclary.com/dom-ts/tests/alltests-suite.html> illustrates the use 
of jsUnit test suites to combine tests. I believe this technique should 
be used rather than the alltests form currently used.

Hope this helps,
Bob

Received on Tuesday, 28 May 2002 02:32:12 UTC