- From: Curt Arnold <carnold@houston.rr.com>
- Date: Thu, 30 Jan 2003 23:46:42 -0600
- To: jeroen@x-hive.com, www-dom-ts@w3.org
Jeroen van Rotterdam wrote: > Ok, so for the framework you suggest testing DOMWriter using pipes > by creating an inputstream from an outputstream ? > > I guess I can live with that. I don't know if we can do much more than check that the same DOM implementation can read the stream back. >>- a method to get the size of a file > > > This is typically used to do weak tests on e.g. pretty print. Since pretty > print is weakly defined you would probably fall back to test whether the > output has a different size than the input after applying pretty-print. > I know this isn't great but it's probably the best you can do. Being able to get a count of the number of times a specific character appeared in a stream might be helpful. If you output 100 elements and the pretty printed stream has no linefeeds, you'd know it wasn't very pretty. > > If we use strings and read from the outputstream I can do it with > String.length(). > > >>Would there be any need (hopefully not) for this to something other than >>a resource provided with the test? > > No, DOMInputSource can have both a DOMInputStream as a DOMReader as an input. I was trying to distinguish between reading files that were provided as part of the test package (like "staff.xml") versus arbitrary file system files. >>Do we want to provide a mechanism to mechanism to create a reader from a >>file? It would be difficult to implement for ECMAScript. It might be >>cleaner just to provide a mechanism to initialize a reader from a string. > > > If we just use strings in tests we won't be able to test System > Exceptions. It is currently still an open issue whether System Exceptions > are passed on and how. If this will be done by a DOMException than it > makes sense to build a test for it (something like parse a non existing > file and find out whether a DOMException is thrown). Populating a character reader from a file would be difficult from JavaScript. However, it should be possible to fill a stock reader implementation from a string and allow a test to provide a custom reader that throws an exception from both Java and JavaScript implementations of DOM. <var name="myFlakyReader" type="DOMReader"> <read> <throw/> </read> </var> or <var name="myStringReader" type="DOMReader" value="<?xml version='1.0'?><foo/>"/>
Received on Friday, 31 January 2003 00:46:48 UTC