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 Monday, 23 April 2001 17:07:38 UTC