Re: DOML3 core test case questions

>>- Test cases for attributes Text.isElementContentWhitespace and
Attr.isId,
>>when transformed to java, appear to get inappropriately prefixed with a
>>"get".  Is there a fix for this?
>
>No, but I knew that this would need to be added since this was a change
>to the production rules.   The plan was to add a test and then fix the
>production.

Attached is a sample test for isElementContentWhitespace.  Hope it helps.
(See attached file: textiselementcontentwhitespace02.xml)


>Boolean.TRUE is way too much of a Java-ism.  Write it as expected="true"
>and I'll make sure the transform and infrastructure do the right thing.

Attached is a sample test case for getParameter.  A variable of type
DOMUserData
is being used to store and verify the returned value of this method.

(See attached file: domconfigurationgetparameter01.xml)


>There is no construct currently to do this.  If really necessary, we can
>add one.  Maybe something like:

Would be nice to have a construct like this.  Attached is a test that can
result in different DOMExceptions.

(See attached file: nodereplacechild01.xml)


>Do you have any plans to commit these tests?
Yes I plan to commit these, hopefully in the next few weeks.


Thanks for your help,
Neil.





                                                                                                                                       
                      Curt Arnold                                                                                                      
                      <carnold@houston.        To:       www-dom-ts@w3.org                                                             
                      rr.com>                  cc:                                                                                     
                      Sent by:                 Subject:  Re: DOML3 core test case questions                                            
                      www-dom-ts-reques                                                                                                
                      t@w3.org                                                                                                         
                                                                                                                                       
                                                                                                                                       
                      11/13/2003 12:36                                                                                                 
                      AM                                                                                                               
                                                                                                                                       




Neil Delima wrote:

>- Test cases for attributes Text.isElementContentWhitespace and Attr.isId,
>when transformed to java, appear to get inappropriately prefixed with a
>"get".  Is there a fix for this?
>
>
>
No, but I knew that this would need to be added since this was a change
to the production rules.   The plan was to add a test and then fix the
production.

>-  Does the test framework support testing methods that either return
>UserDataObject's or accept UserDataObject parameters.
>   For example to test getParameter(...) is something like following
valid?
>
><var name="doc" type="Document"/>
><var name="domConfig" type="DOMConfiguration"/>
><var name="param" type="Booelan"/> <!-- might case validation errors -->
><load var="doc" href="staffNS" willBeModified="false"/>
><domConfig obj="doc" var="domConfig" interface="Document"/>
><getParameter obj="domConfig" var="param" name='"comments"'/>
><assertEquals actual="param" expected='Boolean.TRUE' id="blah"/>  <!--
>again possible validation errors -->
>
>
>
Boolean.TRUE is way too much of a Java-ism.  Write it as expected="true"
and I'll make sure the transform and infrastructure do the right thing.

>- Is there any way of specifying more than one acceptable expected
>exception on a method?
>
>
>

There is no construct currently to do this.  If really necessary, we can
add one.  Maybe something like:

<assertDOMException>
     <AllowableCodes>
            <INDEX_SIZE_ERR/>
            <NO_MODIFICATION_ERR/>
     </AllowableCodes>
     <someStatement/>
</assertDOMException>


Do you have any plans to commit these tests?