|This section is a sort of catalog of existing tests. Beginning users
will probably want to see how to run tests as well.|
Java Test Drivers (data driven testing)
A Java Test Driver executes a test for each xml/xsl file pair in
the specified directory tree or each pair in the specified fileList.
The driver iterates over the inputDir tree or list of files
and asks a Testlet to execute() a test on each one. This is also similar to
data driven testing, where a common algorithim is defined for a test case, and
then a large number of data points (in this case, the xml/xsl file pairs) are run through the test case in order.
The best example is StylesheetTestletDriver.
Another generic example is FileTestletDriver.
The Test Drivers rely on various Testlet implementations
to define the actual testing algorithim to apply to each xml/xsl
file pair. This defines any options to be used when processing the
file as well as logging out information about the test in progress.
The Testlets rely on TransformWrapper
subclasses to perform the actual test of processing or transformation
of the xml/xsl file pair into the output file. We can then plug
in different TransformWrapper "flavors" easily. Different
TransformWrapper can process or transform in various ways, like
using DOM trees, SAX events, or input/output streams.
The three levels of iteration, test algorithim, and
processor flavor are all independently changeable, so we can
easily try out different kinds of tests. This technique is used to
run the full sets of 'conf' (conformance), 'perf' (performance),
extensions, and 'contrib' (user contributed stylesheets) tests.
- This is similar to the StylesheetTestlet, but for Xalan-C.
It simply shells
out to a command prompt to run each stylesheet through the TestXSLT.exe program
Java API tests for the TRAX (or javax.xml.transform) interface, that
Xalan-J 2.x implements.
All in package: org.apache.qetest.trax
|(This Section needs updating: many new tests have been added; see the Javadoc for a list -sc)|
- a template for creating new TRAX API tests, see Submitting New Tests
- utility: wraps javax.xml.transform.ErrorListener, and logs info;
this class also supports setting expected errors to trap, and it will call
logger.checkPass/checkFail for you when it gets an expected or unexpected event.
This allows us to write very detailed negative tests and have them be
- utility: wraps javax.xml.transform.URIResolver, and logs info
- A testing version of samples/trax/Examples.java, a sample file
provided in Xalan-J 2.x showing various uses of the TRAX or
javax.xml.transform API to process stylesheets.
- API coverage tests for javax.xml.transform.Transformer
- API coverage tests for javax.xml.transform.TransformerFactory
- API coverage tests for javax.xml.transform.Templates
- Testing various types and kinds of stylesheets embedded with the xml-stylesheet PI
- API Coverage test for ErrorListener
- Functionality test of error listeners when using illegal stylesheets
- Various tests of programmatic access and changing of output properties
- Testing various forms of URLs in setSystemID with imported and included stylesheets
- Testing various forms of URLs in setSystemID
- MANUALLY executed test for running multiple threads
and transforming multiple stylesheets simultaneously. An updated and automated
test is now available, org.apache.qetest.xsl.ThreadedTestletDriver, which
should be used instead.
All in subpackages of: org.apache.qetest.trax
- API coverage tests for javax.xml.transform.stream.StreamSource
- API coverage tests for javax.xml.transform.stream.StreamResult
- API coverage tests are available with a similar naming scheme for most javax.xml.transform.* classes
A few tests are ones that Xalan does not currently pass due to Bugzilla reports, but we know the
correct ("gold") result by analysis or by trying the test on other processors.
A number of tests may also be missing matching "gold" files, if we haven't
yet had time to confirm the correct output. It's still useful to run these
tests (although the test driver will report an AMBG or 'Ambiguous'
result) because you can still see if the output looks basically correct, and
compare the output to previous test runs before you submit your code changes, etc.
The tests have several different types of results beyond just pass or fail,
which are documented in org.apache.qetest.Logger.