Re: Some LS test-issues

Sander Bos wrote:

>Dear Curt,
>
>  
>
>>>DOMInputSourceTest3
>>> resource resolver should not give back null result, then 
>>>      
>>>
>>parser will look
>>    
>>
>>>for 'new_system' file on filesystem.
>>>      
>>>
>>Current DOMInputSourceTest3 does not have an resource 
>>resolver.  Haven't 
>>checked history.
>>    
>>
>
>My bad, I meant DOMInputSourceTest5.
>  
>

The test apparently was intended to make assertions about the parameters 
on the call to resolveResource, however resolveResource is not involved 
in resolving the document entity.  The inner class method is never 
invoked, the test is effectively a unnecessarily complex test that an 
unresolved URL results in a null return value for document.  The test 
needs to be rewritten.

>  
>
>>>DOMWriterFilterTest0:
>>> <getAttribute var="attr1" obj="elt1" name='"attr1"'/>
>>>discovered during implementation that this does not test whether the whole
>>>      
>>>
>>>attribute is 'accidentally' removed (getAttribute returns empty string for non-existing attributes).  Since I think most impls are likely to get this wrong at first may be idea
>>>      
>>>
>>>to add extra check that attr1 is present (but empty), also to distinguish it
>>>>from next test.
>>>      
>>>

I do not see any attributes in the parsed string and there is no DTD 
that would provide default attributes.

>>>DOMWriterFilterTest1:
>>> The check at the end should verify that the attribute is now gone, not that it is still there as it does now.
>>>      
>>>

The comment in the test is emphatic that the attribute should be 
preserved, but my reading agrees with yours that the attribute should 
have been stripped.

Received on Monday, 29 December 2003 17:06:56 UTC