Re: [General] Language-independent test representation

We have been working on the XML representation of the test
scenarios and an XSLT transformation -- We currently have
this working for all of our Java-based tests and have a java
translator.  I've included an example called node.xml, the
transformation, called generate.xsl, the dtd, methods.dtd, and
a translated file, node.java.  Right now, we are working on
generating javadoc style comments as well, and cleaning up
parantheses that we don't need, etc.  We will also have an
ECMAScript translator -- probably by the end of the week.

Joe is right in that we have ended up having to support much of
the functionality of a programming language, including type
definitions, method calls, for/while loops, assignments, etc, but
we have been able to encapsulate all of our current tests and
don't expect to have any problem generating ECMAScript code.
This approach also has the advantage of being able to generate
code for other languages, such as Perl, Python, C, C++, simply
by adding one more style sheet and a set of language def's for the
dom calls.  It also affords us the ability to maintain one common
code base.

We do have a couple of questions at this point and are looking for
input.  First, our tests load an xml file and associated dtd under a
couple of scenarios -- so, we need support for validating, non-validating,
entities, expanded and not expanded, whitespace, retained, stripped.
Any suggestions on whether this should be handled inside a test, or
more generically by an associated test harness?  Inside the test would
give us stand-alone tests but would force the developer to change the
load mechanism for every test...Outside forces the use of a driver.
We have a similar problem with comparing expected results and
actual results -- should it be done inside the test or with an associated
harness.

Comments/suggestions???

Mary Brady
NIST, Web Technologies
mbrady@nist.gov


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


> > I take it your main point is that it seems to be besides the point to
> > introduce an XML-based vocabulary since we can use the Java
> > form and port it
> > from there.
>
> It has seemed to be extremely trivial to port when
> the test cases have been written to avoid constructs that are
> binding specific.
>
> >
> > Functionally, there is no difference. Code is code (the
> > XML-coded snippet
> > will eventually become code as well). Once you think of the
> > test forming
> > only part of the test _submitted_, allowing for
> > documentation, author info
> > and so forth (which is in XML), I think my point becomes clearer.
> > Streamlining this to allow only for XML-encoded information seems more
> > straightforward.
>
> I guess it depends on the complexity of this additional information.
Documentation and author info could probably be sufficiently addressed
> using Javadoc comments.  If the nature of the additional information
> is sufficiently complex, then a separate XML document that provides
> the additional information could be linked to the tests by test name.
>
> In addition, you could generate a total XML representation by running
> the Java based tests through JavaML to create an XML representation
> and then doing appropriate XSLT transforms.
>
> I don't think that using a JUnit based framework for developing and
> evaluating tests precludes and eventual formulation of an abstract
> XML representation of the tests and it should be relatively easy to
> generate the abstract XML representation after most of the tests have
> been developed.
>
>