Re: [General] Language-independent test representation

Curt,

I have to admit that I haven't followed recent developments in this
community.  Is there a URL that you can forward that explains the
entire testing framework more fully?  I'm not opposed to moving
to this framework if it doesn't distract us further.

--Mary

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: <www-dom-ts@w3.org>
Sent: Monday, April 23, 2001 4:56 PM
Subject: RE: [General] Language-independent test representation


> >   I've only used the PyUnit flavor of xUnit, and have been fairly
> > impressed.  I don't know how simple the translation from one version
> > to another is, however -- I expect things would be different when
> > testing for raised exceptions (they certainly *could* be very
> > different).
>
> Testing exceptions was one thing that I knew was going to be a problem
> (based on previous experience with the ECMAScript harness).  Basically,
> the DOM error codes were not appropriate as COM error codes and basically
> every COM implementation went their own way.  How I addressed this in
> the script is to force evaluation of exceptions down into the base test
> class (the same place I try to hide all binding specific behavior).  So
> in the test case, you will have something like:
>
> try {
>    ...
> }
> catch(DOMException ex) {
>    if(isExpectedException(ex,INDEX_ERR_EXCEPTION)) {
> return;
>    }
> }
> fail(msg);
>
> The DOMException type in the catch statement is removed for JavaScript.
> In the Java and C++ implementations, the exception code is checked against
> the expected value.  On the JavaScript harness, isExpectedException
> always returns true (though the behavior could be enhanced when
> there is a known correspondance between DOM exception codes and HRESULTS).
>
>
> >   The tests for the Python DOM that we've developed at Digital
> > Creations uses PyUnit, and I don't think we could have done it without
> > something like it.  I've not had time to look at the NIST tests to
> > determine possible integration, but we'd certainly like to be able to
> > contribute.  Our tests are freely available from our public anonymous
> > CVS server.
> >
> >  > The sample node.xml still seems to maintain a limitation
> > of one string
> >  > assertion per test.  If we are bringing in tests from
> > other sources,
> >  > this limitation could be barrier to integration.  Plus, it
> > doesn't allow
> >  > any tests of object identity or other type specific tests or
> >  > distinguishing a method returning a string containing
> > "null" vs a null string.
> >
> >   These should be considered real problems.  One of the supposed
> > advantages of xUnit is that it is easy & quick to run a serious set of
> > tests, but having to test (for example) the old and new nodes from
> > Text.splitText() separately seems quite wasteful -- two assertions
> > makes more sense.  This is the case in many instances for the DOM.
>
> Which seems to be the case with tests textSplitTextOne - textSplitTextFour
> in the NIST suite.
>
>

Received on Tuesday, 24 April 2001 11:24:42 UTC