RE: jsUnit, Cross Browser Support, Asynchronous Data

> I am not clear as to some of the modifications that were made 
> to jsUnit 
> for the DOM TS and wanted to discuss/study the rationale behind the 
> changes. Help and guidance would be appreciated here.

I assume that you are talking about the patches that are applied as part of
the DOM TS build process.  Without the patch, test cases needed to reference
jsUnitCore.js (part of JSUnit) which required you to coordinate location of
JSUnit and the test suite.  With the patch, the testRunner checks if there
is an explicit reference for jsUnitCore and if not injects the equivalent
code into the test page.  This eliminates the need for JSUnit and the tests
to always have a fixed relative location.

> One of the features of jsUnit which does not appear to be utilized in 
> the DOM TS at the moment is the "Test Suite". I believe that 
> this would 
> be very helpful in producing different sets of tests which 
> would address 
> the differing needs of browsers.
> 
> For example, it would be useful to have a suite of tests which would 
> require a validating parser. Another set could use 
> minimalistic methods 
> of loading XML documents which did not depend on browser specific 
> methods. Others could use browser specific methods of loading 
> documents 
> such as Document.load or XMLHttpRequest or whatever would be 
> appropriate.

It is not so bad in the ECMAScript world, but the permutations with that
type of approach get huge with other bindings.  For example, if you wanted
to take that approach with the Java parsers, you would need distinct suites
for:

Validating/non-validating
Entity expanding/entity preserving
Namespace aware/namespace unaware
Element whitespace preserving/Element whitespace ignoring
XML/SVG/HTML

The current approach in the Java binding is that members of a test suite
identify themselves as inappropriate for the current document builder by
throwing an exception in the test constructor.

So, for example, if the configuration under test was non-validating, a test
marked as validating would try to run under the same configuration but with
validating enabled, and if that was not possible, then it would throw an
exception in the test constructor which would cause it to be skipped.

Unfortunately, JSUnit didn't provide a mechanism to have a test to report
itself as non-applicable.  With the new pre-test hook, maybe we can do the
same thing that we do in the Java test constructor.

The current JSUnit test "sniffs" a configuration based on the running
browser and selected media type since there was no available mechanism to
allow the user to configure the parser under test.  In the stuff that I was
doing with the browser host, you could control the parser configuration
under test in the test runner.  Possibly, the same type of configuration
could be incorporated with the pre-test phase.

Received on Monday, 1 April 2002 14:10:26 UTC