You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@xalan.apache.org by cu...@apache.org on 2002/05/10 04:32:55 UTC
cvs commit: xml-xalan/test/java/xdocs/sources/tests design.xml faq.xml getstarted.xml overview.xml run.xml
curcuru 02/05/09 19:32:55
Modified: test/java/xdocs/sources/tests design.xml faq.xml
getstarted.xml overview.xml run.xml
Log:
Overall documentation cleanup and updates: remove deadwood,
update design and basic how-tos
Revision Changes Path
1.5 +18 -3 xml-xalan/test/java/xdocs/sources/tests/design.xml
Index: design.xml
===================================================================
RCS file: /home/cvs/xml-xalan/test/java/xdocs/sources/tests/design.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- design.xml 21 Aug 2001 19:58:31 -0000 1.4
+++ design.xml 10 May 2002 02:32:55 -0000 1.5
@@ -219,6 +219,21 @@
<code>cd xml-xalan\test</code><br/>
<code>build contrib -Dqetest.category=foo</code><br/>
</p>
+ <p>Tests using Xalan Extensions may be found under test/tests/extensions and are separated
+ into directories by language:<br/>
+ <gloss>
+ <label>test/tests/extensions/library</label>
+ <item>Stylesheets for extensions implemented natively in Xalan; these only
+ have .xsl and .xml files for the test</item>
+ <label>test/tests/extensions/java</label>
+ <item>Stylesheets for extensions implemented in Java; these are run by
+ a .java file that uses an ExtensionTestlet to run</item>
+ <label>test/tests/extensions/javascript</label>
+ <item>Stylesheets for extensions implemented in Javascript; these include
+ only a .xsl and .xml file but require
+ <jump href="http://xml.apache.org/xalan-j/extensions.html#supported-lang">bsf.jar and js.jar</jump> in the classpath</item>
+ </gloss>
+ </p>
</s2>
@@ -241,9 +256,9 @@
<ul>
<li><jump href="http://www.soft.com/Institute/HotList/index.html">Software Research Institute HotList</jump>
This is a pretty good laundry list of top-level links for software testing</li>
- <li><jump href=""></jump>In progress</li>
- <li><jump href=""></jump></li>
- <li><jump href=""></jump></li>
+ <li><jump href="http://www.swquality.com/users/pustaver/index.shtml">SWQuality site; plenty of links</jump></li>
+ <li><jump href="http://www.stickyminds.com/">StickyMinds</jump></li>
+ <li><jump href="http://www.sqe.com/press/index.asp">SQE</jump></li>
</ul>
</s2>
</s1>
1.3 +13 -0 xml-xalan/test/java/xdocs/sources/tests/faq.xml
Index: faq.xml
===================================================================
RCS file: /home/cvs/xml-xalan/test/java/xdocs/sources/tests/faq.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- faq.xml 25 Jan 2002 23:46:42 -0000 1.2
+++ faq.xml 10 May 2002 02:32:55 -0000 1.3
@@ -50,6 +50,19 @@
</ul>
</s2>
+ <anchor name="xsltc"/>
+ <s2 title="Run XSLTC-related tests">
+ <p>Note that currently some of the XSLTC-specific tests are
+ built with separate targets; in the future as the XSLTC engine
+ is more completely integrated into the Xalan core, we hope to
+ merge the tests as well.</p>
+ <p>Note that many of the tests that use TrAX/JAXP should work
+ equally well with XSLTC since they have their own version of
+ a TransformerFactory; remember to set the appropriate system
+ property or classpath appropriately. The various org.apache.qetest.trax
+ API tests should also work normally with XSLTC.</p>
+ </s2>
+
<anchor name="xsltmark"/>
<s2 title="Run XSLTMARK perf tests">
<p>Xalan has it's own more detailed automation harness for running
1.6 +36 -49 xml-xalan/test/java/xdocs/sources/tests/getstarted.xml
Index: getstarted.xml
===================================================================
RCS file: /home/cvs/xml-xalan/test/java/xdocs/sources/tests/getstarted.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- getstarted.xml 5 Sep 2001 18:55:06 -0000 1.5
+++ getstarted.xml 10 May 2002 02:32:55 -0000 1.6
@@ -10,13 +10,16 @@
<anchor name="quickstart"/>
<s2 title="Quick Start">
- <note>This section assumes you are already familiar with building Xalan-J and with Ant.</note>
+ <note>This section assumes you are already familiar with
+ <jump href="http://xml.apache.org/xalan-j/readme.html#build">building Xalan-J</jump> and with
+ <jump href="http://jakarta.apache.org/ant/">Ant</jump>.</note>
<p>Set JAVA_HOME, and have your classes.zip or tools.jar in the CLASSPATH.</p>
+ <p>Here are some sample commands to build and run tests:</p>
<p><code>cd /builds </code>
<br/><code>checkout xml-xalan/java </code> Get the Xalan-J code (or simply get a nightly build or distro)
<br/><code>cd xml-xalan/java </code>
<br/><code>build jar </code> Build Xalan-J as usual
- <br/><code>build smoketest </code> Run the build Smoketest (simply calls the smoketest target below)
+ <br/><code>build smoketest </code> Run the build Smoketest (optional; simply calls the smoketest target below)
</p>
<p><code>cd /builds </code>
<br/><code>checkout xml-xalan/test </code>
@@ -33,25 +36,27 @@
<br/><code>build bugzilla.classes </code> Compile the tests/bugzilla bug regression tests
<br/><code>build bugzilla </code> Run the tests/bugzilla bug regression tests
<br/><code>build clean </code> Clean up the built automation (does not clean any results you've generated)
+ <br/><code>build -h </code> Get help on build.bat/build.sh options and Ant targets
</p>
<p>Changing options:</p>
- <p>Now that we use the Ant test/build.xml script to kick off tests, <link idref="run" anchor="test-options">test options</link>
+ <p>Since we use the Ant test/build.xml script to kick off tests, <link idref="run" anchor="test-options">test options</link>
get passed slightly differently. The actual options the tests see and use
remain the same as before, however when you invoke Ant you need to specify the
- options with a prefix that Ant uses and then strips off.</p>
+ options with a -D and a prefix that Ant uses and then strips off in XSLTestAntTask.</p>
<p>Default options (inputDir, loggingLevel, etc.) are now all stored in test.properties.
Overall defaults are prefixed with <code>qetest.</code>, which are used if no other
type of test is specified. Each type of test (api, conf, perf, contrib, etc.) has
- it's own set of some prefixed options - namely inputDir, outputDir, goldDir and
- logFile.</p>
+ it's own set of some prefixed options - namely api.inputDir, api.outputDir, api.goldDir and
+ api.logFile, etc..</p>
<p>Users may override the defaults in one of two ways:</p>
<ul>
- <li>Create a my.test.properties file with any options you wish to use. This will
+ <li>Create a <code>my.test.properties</code> file with any options you wish to use
+ in the xml-xalan/test directory. This will
override any options set in the test.properties or build.xml files. The format
- is the same as the test.properties file. The name of this file may be specified
+ is the same as the test.properties file. A different name of this file may be specified
using -Dlocal.properties=new.name.properties on the command line</li>
<li>Pass options on the command line. This is the same as passing options to
- java or your JDK, so you must use the -Dname=value format.</li>
+ java or your JDK, so you must use the <code>-Dname=value</code> format.</li>
</ul>
<p><code>build conf -Dconf.category=axes -Dconf.flavor=trax.sax </code> This runs
the normal conf tests, but only on the axes subdir, and using the TraxSaxWrapper class.
@@ -81,26 +86,26 @@
development sources and the test sources (they are just source, however, and are not prebuilt), or:
<br/><br/>Get the latest <jump href="http://xml.apache.org/xalan-j/dist/nightly/">GUMP build output</jump>:
which includes full compiled distribution builds as well as a full set of
- prcompiled tests and test results.
+ prcompiled tests and test results in a *smoketest.tar.gz file.
</p>
</s2>
<anchor name="how-to-build"/>
<s2 title="Building the Tests">
- <note>Please use the new xml-xalan/test/build.xml file - the old xml-xalan/test/java/build.xml
- file is deprecated and will be removed soon.</note>
<p>Since the test automation is written in Java, you must build it before running
any tests. Like Xalan-J, we use Ant build.xml files as 'makefiles' to build the
- project. A copy of the Ant runtime files is provided in the /bin directory if you
+ project. A copy of the Ant runtime files is provided in the xml-xalan/java/bin directory if you
need them; you may also use your own copy of Ant if you have it installed.
Unless specifically noted, all testing code should work either on Windows or
- UNIX systems; adjust .sh/.bat and path\separators/as needed.</p>
+ UNIX systems; adjust .sh/.bat and path\separators/as needed. Note that paths
+ in .properties files may always use forward / slashes since Ant's path
+ handling will always do the proper thing.</p>
- <p>This assumes you already have a version of Xalan-J in e:\builds\xml-xalan\java
+ <p>This assumes you already have a version of Xalan-J in \builds\xml-xalan\java
This may either be a distribution or a copy you pulled from CVS and built yourself.</p>
<p>Download the tests to \builds\xml-xalan\test.</p>
- <p><code>cd e:\builds\xml-xalan\test </code>
+ <p><code>cd \builds\xml-xalan\test </code>
<br/><code>build jar </code> This calls build.bat/.sh to find a copy of ant.jar and an
xml parser (which Ant requires). It then calls Ant to run the 'jar' target in the
default build.xml file. This will compile all the base test reporting libraries and
@@ -110,47 +115,29 @@
and xml-xalan/test directories locally, as if you were a developer on xalan. See below
for a simple alternate way to set your classpath using JARDIR. This allows QE/QA/test
people to run the same set of tests quickly against different versions of the product.</p>
- <note>(Aug-01 Section needs updating: JARDIR docs -sc)</note>
- <p>ALTERNATE way using JARDIR:</p>
- <p>1: Set an environment variable JARDIR to point to directory where you have all applicable jars.
- <br/>Delete testxsl.jar if already present there (if you want to rebuild it).
- <br/>Required: at least xalan.jar and bsf.jar from a Xalan-J build;
- xerces.jar from the <ref>same</ref> Xalan-J build (or your parser's JAXP-compatible jar instead of xerces.jar);
- and js.jar (see <jump href="http://xml.apache.org/xalan-j/extensions.html#supported-lang">Xalan-J doc for information on js.jar, only needed for extensions tests</jump>)
- <br/><code>set JARDIR=e:\builds\myjars </code>
- </p>
- <p>2: Copy needed product jars to the JARDIR</p>
- <p>3: cd to the test directory and cleanup the tests</p>
- <p><code>cd e:\builds\xml-xalan\test </code>
- <br/><code>build clean </code>
- </p>
- <p>4: Build the tests
- <br/><code>build jar </code>
- </p>
- <p>This will create <code>build\testxsl.jar </code>, which you should manually copy
- into JARDIR before you <link idref="run" anchor="how-to-run">run any tests</link>.
- Note that you might instead want to <code>build all</code> if you want to also
- run any of the bugzilla or extensions tests as well.</p>
- <note>The use of JARDIR is not required; you're free to manage the classpath
- yourself, or the test build file will assume it should use the Xalan-J 2.0
- directories by default. I've found that simply putting all the needed jars in
- a JARDIR makes it simple to switch between testing different builds.</note>
+ <note>Using JARDIR is no longer fully supported due to lack of
+ interest. Those wishing to manage custom classpaths are welcome
+ to submit patches to allow this in an automated fashion.</note>
+ <p>The default jar target builds all TestletDrivers and most of the tests.
+ A few kinds of tests require separate targets to compile since they have
+ extra dependencies. In particular, any XSLTC-specific API tests or
+ TransformWrapper subclasses are compiled in a separate set of targets.</p>
+
+ <p>Users of automated IDE's that automatically compile all *.java files
+ in the source tree will either have to use the Ant build.xml script or may
+ have to manually compile certain files with the extra dependencies. Note that
+ JUnit is only required for the special qetesttest directory, which is only used to
+ test the qetest framework itself and is not needed to test Xalan.</p>
<p>Note that there are a few precompiled .class files in the test/java/src/ area.
By default these are simply copied into the testxsl.jar for you. These are files
that require extra dependencies to compile, and change infrequently, so as a
- convenience they're checked in precompiled as well as source.</p>
- <p>Building the <link idref="run" anchor="how-to-run-c">CConformanceTest</link>
- for testing Xalan-C currently is done with <code>build.bat package.xsl </code>.
- Instructions for building/running other Xalan-C API tests are still to be written.</p>
+ convenience they're checked in to the repository as precompiled .class files as well as source.</p>
<p>Building the Javadocs for the tests is done by <code>build.bat javadocs </code>, and
is best done under JDK 1.2.2 or higher - they will build with JDK 1.1.8, but not
all the links will work properly.</p>
<p>Building these top-level documents in the xdocs directory can
be done with <code>build.bat docs </code> and must be done under JDK 1.2.2 or higher,
- since the Xalan-related stylebook code that we use requires that. Note also that
- building the docs may require a Xalan-J 1.x build, since we use Xalan to
- process the source XML documents into HTML (and we currently have it setup
- for the 1.x build).</p>
+ since the Xalan-related stylebook code that we use requires that. </p>
</s2>
</s1>
1.8 +29 -39 xml-xalan/test/java/xdocs/sources/tests/overview.xml
Index: overview.xml
===================================================================
RCS file: /home/cvs/xml-xalan/test/java/xdocs/sources/tests/overview.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- overview.xml 19 Apr 2002 12:49:41 -0000 1.7
+++ overview.xml 10 May 2002 02:32:55 -0000 1.8
@@ -27,13 +27,16 @@
<p>The Xalan tests include a richly featured and fully automated testing framework
that the great majority of the tests use. The org.apache.qetest package provides
an independent testing and automation harness for Xalan, including logging and
- reporting mechanisims.</p>
+ reporting mechanisims. The basic framework is easily used in testing
+ other programs as well since dependencies on Xalan and an XML parser are
+ clearly compartmented.</p>
<p>Nearly all tests are automated, run without any user interaction and with a minimum amount of setup, and produce
a rolled-up report of their pass/fail/other status. Our existing testing library includes
a wide array of tests, from XSLT conformance to detailed API tests, and welcomes
user-submitted tests as well. The 'smoketest' target (a subset of the most important
tests) are also integrated into the <jump href="http://jakarta.apache.org/builds/gump">GUMP nightly build system</jump>, and thus ensure a
- minimum baseline of functionality on a daily basis.</p>
+ minimum baseline of functionality on a daily basis. Developers can run the smoketest
+ and ensure it passes before checking in code changes.</p>
</s2>
<anchor name="dir-map"/>
@@ -43,10 +46,11 @@
<label><code>xml-xalan/test</code></label>
<item>Top level dir for all Xalan versions/products tests</item>
<label></label>
- <label><code>xml-xalan/test/bin</code></label>
- <item>Java test automation dependencies (includes
- <jump href="http://jakarta.apache.org/ant/index.html">Ant 1.2</jump>
- so that you don't have to install it yourself)</item>
+ <label><code>xml-xalan/test/bin</code> (no longer included)</label>
+ <item>All dependent .jar files, (including
+ <jump href="http://jakarta.apache.org/ant/index.html">Ant</jump>
+ and the Xerces parser) are included in the corresponding xml-xalan/java development
+ tree</item>
<label><code>xml-xalan/test/java/src</code></label>
<item>Java test automation source tree - this includes
a generic testing framework as well as specific API tests for parts of Xalan
@@ -60,6 +64,7 @@
<jump href="apidocs/org/apache/qetest/trax/stream/package-summary.html">org.apache.qetest.trax.stream</jump><br/>
<jump href="apidocs/org/apache/qetest/trax/sax/package-summary.html">org.apache.qetest.trax.sax</jump><br/>
<jump href="apidocs/org/apache/qetest/xalanj2/package-summary.html">org.apache.qetest.xalanj2</jump><br/>
+ <jump href="apidocs/org/apache/qetest/dtm/package-summary.html">org.apache.qetest.dtm</jump><br/>
<br/></item>
<label><code>xml-xalan/test/tests</code></label><item>Top level for XSLT stylesheet trees and special API tests</item>
<label><code>xml-xalan/test/tests/conf</code></label><item>Directory tree of specific conformance testing stylesheets</item>
@@ -80,6 +85,7 @@
<label><code>xml-xalan/test/tests/extensions/java</code></label><item>Tests for extensions written in Java</item>
<label><code>xml-xalan/test/tests/extensions/javascript</code></label><item>Tests for extensions written in Javascript</item>
<label><code>xml-xalan/test/tests/extension-gold</code></label><item>Matching Directory tree of gold files for extensions tests<br/></item>
+ <label><code>xml-xalan/test/tests/bugzilla</code></label><item>Special directory of stylesheets and automated Testlets reproducing selected Bugzilla bug reports</item>
</gloss>
</s2>
@@ -87,16 +93,17 @@
<s2 title="Listing of Java tests and drivers">
<note>This section is a sort of catalog of existing tests. Beginning users
will probably want to see <link idref="run" anchor="how-to-run">how to run tests</link> as well.</note>
-<p>Java Test Drivers (data driven testing</p>
+<p>Java Test Drivers (data driven testing)</p>
<p>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.
-For each test, the driver iterates over the tree or list of files
-and asks a Testlet to execute a test on each one. This is also similar to
+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 <jump href="apidocs/org/apache/qetest/xsl/StylesheetTestletDriver.html">StylesheetTestletDriver</jump></p>
+The best example is <jump href="apidocs/org/apache/qetest/xsl/StylesheetTestletDriver.html">StylesheetTestletDriver</jump>.
+Another generic example is <jump href="apidocs/org/apache/qetest/FileTestletDriver.html">FileTestletDriver</jump>.</p>
<p>The Test Drivers rely on various Testlet implementations
-to define the actual testing algorithim to apply to each xml.xsl
+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.
Examples include
@@ -104,7 +111,7 @@
<jump href="apidocs/org/apache/qetest/xsl/PerformanceTestlet.html">PerformanceTestlet</jump></p>
<p>The Testlets rely on <jump href="apidocs/org/apache/qetest/xslwrapper/TransformWrapper.html">TransformWrapper</jump>
subclasses to perform the actual test of processing or transformation
-of the xml.xsl file pair into the output file. We can then plug
+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.</p>
@@ -114,18 +121,17 @@
run the full sets of 'conf' (conformance), 'perf' (performance),
extensions, and 'contrib' (user contributed stylesheets) tests.</p>
<gloss>
-<label>org.apache.qetest.xsl.<link idref="run" anchor="how-to-run-c">CConformanceTest</link></label>
+<label>org.apache.qetest.xsl.<link idref="run" anchor="how-to-run-c">XalanCTestlet</link></label>
<item>This is similar to the StylesheetTestlet, but for Xalan-C.
-It has a different method of discovering test files, and simply shells
-out to a command prompt to run each stylesheet through the TestXSLT.exe program.
-I plan to make this use the Testlet model soon to simplify this model, and
-to provide better support for differing command lines.</item>
+It simply shells
+out to a command prompt to run each stylesheet through the TestXSLT.exe program
+from Xalan-C.</item>
</gloss>
<p>Java API tests for the TRAX (or javax.xml.transform) interface, that
Xalan-J 2.x implements.<br/>
All in package: org.apache.qetest.trax</p>
-<note>(Aug-01 Section needs updating: many new tests have been added -sc)</note>
+<note>(This Section needs updating: many new tests have been added; see the Javadoc for a list -sc)</note>
<gloss>
<label>REPLACE_template_for_new_tests.java</label>
<item>a template for creating new TRAX API tests, see <link idref="submit" anchor="write-API-tests">Submitting New Tests</link></item>
@@ -176,37 +182,21 @@
<label>stream.StreamResultAPITest.java</label>
<item>API coverage tests for javax.xml.transform.stream.StreamResult</item>
-<label>dom.DOMSourceAPITest.java</label>
-<item>API coverage tests for javax.xml.transform.dom.DOMSource</item>
-<label>dom.DOMResultAPITest.java</label>
-<item>API coverage tests for javax.xml.transform.dom.DOMResult</item>
-<label>dom.DOMLocatorAPITest.java</label>
-<item>API coverage tests for javax.xml.transform.dom.DOMLocator (@todo)</item>
-
-<label>sax.SAXSourceAPITest.java (to be done)</label>
-<item>API coverage tests for javax.xml.transform.sax.SAXSource</item>
-<label>sax.SAXResultAPITest.java (to be done)</label>
-<item>API coverage tests for javax.xml.transform.sax.SAXResult</item>
-<label>sax.SAXTransformerFactoryAPITest.java (to be done)</label>
-<item>API coverage tests for javax.xml.transform.sax.SAXTransformerFactory</item>
-<label>sax.TemplatesHandlerAPITest.java (to be done)</label>
-<item>API coverage tests for javax.xml.transform.sax.TemplatesHandler</item>
-<label>sax.TransformerHandlerAPITest.java (to be done)</label>
-<item>API coverage tests for javax.xml.transform.sax.TransformerHandler</item>
+<label>etc.</label>
+<item>API coverage tests are available with a similar naming scheme for most javax.xml.transform.* classes</item>
</gloss>
-<p>Some tests are ones that Xalan has not passed to date, but we know the
+<p>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 ConformanceTest driver will report an AMBG or 'Ambiguous'
+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.</p>
<p>The tests have several different types of results beyond just pass or fail,
which are documented in <jump href="apidocs/org/apache/qetest/Logger.html#PASS_RESULT">org.apache.qetest.Logger</jump>.
-At Lotus/IBM, we have some additional test cases that we can't give away, so a
-patch may pass all these tests and fail others, but those cases should be rare.</p>
+</p>
</s2>
1.7 +18 -3 xml-xalan/test/java/xdocs/sources/tests/run.xml
Index: run.xml
===================================================================
RCS file: /home/cvs/xml-xalan/test/java/xdocs/sources/tests/run.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- run.xml 5 Sep 2001 18:55:06 -0000 1.6
+++ run.xml 10 May 2002 02:32:55 -0000 1.7
@@ -21,6 +21,8 @@
for their inputs, so you can run them without any setup at all.
However we have provided a couple of more
convenient ways to run the most common tests:</p>
+ <note>If you need to debug into the tests themselves,
+ you may want to use the <link idref="faq" anchor="debug">debug*.bat files</link></note>
<p>Of course, first <link idref="getstarted" anchor="how-to-build">Build a fresh copy of testxsl.jar.</link>
</p>
<p>cd xml-xalan\test<br/></p>
@@ -65,13 +67,22 @@
more output shown in the results (higher numbers up to 99 show more details,
lower numbers, down to 0, show fewer details).
</p>
+ <p>Future work includes greatly updated results analysis stylesheets.
+ See FailScanner.xsl and PerfScanner.xsl for ideas. An important design
+ principle in the tests is that at runtime the tests merely output
+ whatever data they can as results are generated; afterwards, we then
+ post-process the results into whatever presentation format is needed,
+ including perhaps re-calculating overall results (example: if we have
+ a list of known fails correlated to Bugzilla numbers, then a stylesheet
+ could filter out these fails and report them as known bugs instead.
+ </p>
</s2>
<anchor name="test-options"/>
<s2 title="Common Test Options">
<note>Section needs updating to reflect the fact that while the options the
tests see remain as below, the user must now prefix all optionNames with
'qetest.' or 'conf.', etc. when passing the options on the command line or
- via my.test.properties or test.properties Aug-01 -sc</note>
+ via my.test.properties or test.properties -sc</note>
<p>Most tests can either accept options from a properties file, via:<br/>
<code> TestName -load file.properties</code><br/><br/>
or simply from the command line (which overrides the properties file) like:<br/>
@@ -118,10 +129,14 @@
<item>(read in a .properties file, that can set any/all of the other opts)
This option is automatically used by the Ant build.xml file, so you normally
would not specify it yourself.</item>
- <label>-debug</label>
- <item>prints extra test debugging info</item>
</gloss>
<p>Note that most options work equivalently with either Xalan-J or Xalan-C tests.</p>
+ <p>When running tests using Ant, the <xalantest> task actually
+ marshalls various Ant variables and uses the precompiled org.apache.qetest.xsl.XSLTestAntTask
+ to actually execute the test (either in the same JVM or forked depending on
+ ${fork-tests}. It simply strips the appropriate set of prefixes
+ off of required Ant variables and dumps them into an XSLTestAntTask.properties
+ file on disk, which it tells the test executing to -load.</p>
</s2>
<anchor name="how-to-run-c"/>
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-cvs-help@xml.apache.org