More updates to the Xalan-J 2.x tests. Any feedback appreciated. I know
at least four people who've actually been looking at the tests...
Basic setup steps: (Yes, I'll have real docs later, but this should get
anyone familiar with our builds running right away).
checkout xml-xalan/java
build jar xsltc.jar
checkout xml-xalan/test
build all
---- xsltc automated conf/api tests ----
Tom Amiro is using these targets now to get the xsltc stuff passing more
conformance tests, and also to support the full TRaX/JAXP interfaces from
the xsltc module. Still a ways to go but great progress!
build conf.xsltc
(Runs normal conformance test with xsltc; works well)
build api.xsltc -DtestClass=trax.TransformerAPITest
(Runs a specific api test with xsltc; note only trax tests are
currently valid, and we're still investigating the preliminary results of
test runs for possible quirks between some test's handling of inputDir and
xsltc's handling of input URIs)
---- Extensions automated tests ----
build extensions.classes (was called from build all)
build extensions
This runs the normal StylesheetTestletDriver over the new
xml-xalan/test/tests/extensions directory tree. Extensions tests are setup
basically the same way as conf tests; except that the extensions/java
directory can have a matching foo.java file for it's foo.xsl/.xml file.
foo.java implements TestableExtension, which gets called from the
ExtensionTestlet, so any Java-based extensions can do their own validation.
Note that using the standard driver means that these tests can support
-flavor, etc. as well.
Note that I'm not really happy with the design of TestableExtension: I'd
rather it be an interface, so as not to interfere in extensions themselves,
but I also want preCheck/postCheck to be static to make it simpler to
validate counters, etc. But it does the job quite nicely for now.
I've implemented a few of the samples as tests here; I'll move over the
other javascript one once I convert it to not use new Date(), since that's
a pain to automate (use static data instead of random or time-dependent
data when possible in tests...). I'm sure Gary will have some comments
8-), and if John G. wants some testing space we should create an
extensions/sql directory that we can customize for sql-specific testing.
Just remember, the tests need to be deterministic and should pass when run
through the automation on a current CVS tree of xalan. (And continue to
pass, unless of course a new bug appears!)
---- Bugzilla automated tests ----
build bugzilla.classes (was called from build all)
build bugzilla
Uses a custom BugzillaTestletDriver to iterate just through tests/bugzilla.
Will either execute Bugzillafoo.java as a Testlet (if your bug requires API
calls to run/validate) or will just transform Bugzillafoo.xsl as if it were
a normal conf-like test. Note that gold.out files are checked into this
directory, instead of into a separate bugzilla-gold directory; this is one
difference from other tests.
- Shane
