Re: Writing DOM Level 3 Load & Save tests

> I'm currently investigating the effort for converting our existing DOM
> Level 3 L&S tests to the framework.
>
> I'm only scratching the surface here, I has been a while since I've
> looked into the testsuite in detail, so forgive me if questions have be
> asked before.
>
> Issues:
>
> 1. The current frameworks relies on a load methods in the framework that
> loads a document. Based on that parsed documents tests are written.
> With Load and Save this is not very usefull because you need to test the
> load.

You wouldn't use <load>, you'd use something like:

<var name="docls" type="DocumentLS"/>
<implementation var="impl"/>
<createDocument var="docls" obj="impl" tagname="dummy"/>
<load interface="DocumentLS" obj="docls"/>

> 2. The schema for DOM L3 and the stylesheets to produce the tests aren't
> available as far as I can see, writing a first test is therefore pretty
> tough because there is no way you can get an DOMImplementationLS.

I've made some light attempts at generating a DOM LS schema and DTD, but
didn't perserve since there wasn't anyone immediately interested in it.
I'll see what I can do.  It does not require waiting for the drafts to move
to a recommendation status.

> 3. Testing serialization is difficult as well in the current framework
> because there are no tools to test the serialized form. Sure you could
> reparse it but that is not a good basis to test the serialized form
> since the document may/will change during parsing. Examples here are
> pretty-print, discard-default-content etc.

> 4. DOMInputSource, DOMEntityResolver, DOMBuilderFilter, DOMWriterFilter
> and DOMErrorHandler don't have a factory method. The test needs to
> provide an implementation that implements the interface. Any ideas on
> how to solve this in the framework.

There are some hints of this in the test language with, so far unused,
language elements that I put in to support testing DOM L2 Events
(EventMonitor.*, handleEvent).  The xmlconf DOM L2 Events test used a stock
implementation of EventListener that would capture all the events, so that
you could query it after the mutation.

handleEvent basically was intended to be used to define something like an
anonymous inner class.

<var name="myHandler" type="EventListener">
   <handleEvent return="true">
        <!--  body of method goes here -->
    </handleEvent>
</var>

Take a look at the xmlconf event tests
(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlconf/domunit/JUNIT/NET/so
urceforge/XMLCONF/DOMUNIT/dom2/events/) and see the approach that I took
there.

Received on Wednesday, 20 March 2002 12:08:58 UTC