- From: Dimitris Dimitriadis <dimitris@ontologicon.com>
- Date: Fri, 24 May 2002 14:56:46 +0200
- To: "Curt Arnold" <carnold@houston.rr.com>
- Cc: <www-dom-ts@w3.org>
I'm all for a solution like that. In this way, we ensure that each implementation is tested on its own merits, which has been discussed earlier. On the other hand, we'd need to steer clear of having to rewrite too much of the existing test chain (the stylesheets and build.xml, basically) and try to make the latest version of JsUnit as compatible as possible with what we've done so far. /Dimitris On Friday, May 24, 2002, at 07:39 AM, Curt Arnold wrote: > Robert Clary wrote: >> Ok. I will put together an example and post it so we can use it as a >> straw man for discussion. > > My first inclination is to allow a JSUnit test page to be able to > provide a > configuration page in a frame. Something like: > > 1) Select the test from the browse button > 2) The contents of the configuration page appears in a frame below the > test > selection. The page would allow you to select implementation and > configuration (validating/non-validating, preserve entities/expand > entities, > etc). The configuration page for the test would either be implied from > the > filename or might be determined by loading the test and evaluating a > function. > 3) When the test is run, a JSUnit method can be used to obtain the > configuration document. > > Whether that is possible cross browser, I don't know. > > The boilerplate DOM TS code should hide all the gore from the DOM test > itself. The tests should be oblivious to the details of implementation > selection. > > > >
Received on Friday, 24 May 2002 08:56:49 UTC