Re: TS question

Jeroen van Rotterdam wrote:
>With the limited knowledge I've got now from the DTD I'm trying to image how a test for 
>a DOM L3 LS call would look like.
>
>example:
>
>void       writeNode(in DOMOutputStream destination, in Node node) raises(DOMSystemException);

>Would probably something like <DOMWriter.writeNode var="........

I think this is similar to problems that you would also encounter in writing tests to test event 
dispatching and probably traversals (but I don't know traversals).  Definitely I don't think we want 
our little language to grow to the point that we can extend arbitrary interfaces.

I did a few initial tests for event dispatch and the approach that I thought was reasonable was to
have a build-in implementation of the listener (or in this case DOMOutputStream) that captured
all the events (or output) and allowed you to insert code into the event handler.  You could
make assertions in the event handler or after event dispatching was complete.

I started with some event tests in Java with Junit:


http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlconf/domunit/JUNIT/NET/sourceforge/XMLCONF/DOMUNIT/dom2/events/eventtarget.java?rev=1.1&content-type=text/vnd.viewcvs-markup

and then added the minimal language constructs that allows to be represent that test.  Which in my schema was the <declare><onEvent/></declare>, the EventMonitor.* elements and the EventMonitor datatype.

I would assume a similar approach would work for Traversals and Serialization.  Determine what you
want to test and prototype a few in the language of your convienience and then add a few constructs
to support those types of tests.