[cddlm] Re: CDL Testcase Presentation

Steve Loughran steve_loughran at hpl.hp.com
Thu Nov 3 05:54:21 CST 2005


Stuart Schaefer wrote:
> I did not receive Jun's document in my email, so I apologize for not
> having read it before our meeting.  Here are my thoughts as discussed at
> today's meeting.
> 
>  
> 
> 1)       Use the RDF approach.  CDL test documents should be specified
> as pairs.  Pre and post parsing.  Each of our DOM/XOM engines can spit
> out the final results of parsing as a CDL.

Having it as separate documents would be slightly more fiddly, but could 
permit more usages. Of course, in theory. XSL permits the generation of 
separate documents from a unified source, just as xml:include goes the 
other way. they say.

> 
> 2)       I don't think it is worth the time to create an automated
> "equivalence" tester for comparing the CDL provided in the test case
> output with the output of our own parser.  We should be able to spot
> check results for compliance easily enough.  Just my opinion.  Document
> equivalence is more of an XML problem than a CDL one.

no, no, we must have automated test validation, otherwise -no automated 
tests. the trick is to have validation that is not too-strict to parse 
or too-loose to let things by.

This is the axis2 comparator. It recurses down the graph asserting that
  -elements and namespaces match
  -attributes are present and matching values (order is ignored)
  -all child nodes match

personally I'd skip comments as we dont spec what happens to them, but 
otherwise this is the comparison routine I'm going to use. It aint 
canonical xml, but its a good 'semantic equivalence' test.


     public static void compare(Element ele, OMElement omele) throws 
Exception {
         if (ele == null && omele == null) {
             return;
         } else if (ele != null && omele != null) {
             TestCase.assertEquals("Element name not correct",
                     ele.getLocalName(),
                     omele.getLocalName());
             if (omele.getNamespace() != null) {
                 TestCase.assertEquals("Namespace URI not correct",
                         ele.getNamespaceURI(),
                         omele.getNamespace().getName());

             }

             //go through the attributes
             NamedNodeMap map = ele.getAttributes();
             Iterator attIterator = omele.getAllAttributes();
             OMAttribute omattribute;
             Attr domAttribute;
             String DOMAttrName;
             while (attIterator != null && attIterator.hasNext() && map 
== null) {
                 omattribute = (OMAttribute) attIterator.next();
                 Node node = map.getNamedItemNS(
                         omattribute.getNamespace().getName(),
                         omattribute.getLocalName());
                 if (node.getNodeType() == Node.ATTRIBUTE_NODE) {
                     Attr attr = (Attr) node;
                     TestCase.assertEquals(attr.getValue(),
                             omattribute.getAttributeValue());
                 } else {
                     throw new OMException("return type is not a 
Attribute");
                 }

             }
             Iterator it = omele.getChildren();
             NodeList list = ele.getChildNodes();
             for (int i = 0; i < list.getLength(); i++) {
                 Node node = list.item(i);
                 if (node.getNodeType() == Node.ELEMENT_NODE) {
                     TestCase.assertTrue(it.hasNext());
                     OMNode tempOmNode = (OMNode) it.next();
                     while (tempOmNode.getType() != OMNode.ELEMENT_NODE) {
                         TestCase.assertTrue(it.hasNext());
                         tempOmNode = (OMNode) it.next();
                     }
                     compare((Element) node, (OMElement) tempOmNode);
                 }
             }


         } else {
             throw new Exception("One is null");
         }
     }

> 
> 3)       Is it possible to defer the lazy reference tests to the
> Component Model test phase?  In CDL you need to simply verify that the
> document is properly formed, not that the value turned out as expected.
> That is the responsibility of the Deployment API and Component Model.

Exactly.





More information about the cddlm-wg mailing list