curcuru 01/08/21 12:58:31
Modified: test/java/xdocs/sources/tests design.xml getstarted.xml
overview.xml run.xml
Log:
First draft of new test methods; much better but still needs updates
Revision Changes Path
1.4 +10 -4 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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- design.xml 2001/03/02 00:50:08 1.3
+++ design.xml 2001/08/21 19:58:31 1.4
@@ -35,7 +35,9 @@
automatically by a test driver; contributed tests, which are
stored in tests\contrib, where anyone is invited to submit their
own favorite stylesheets that we can use to test future Xalan
- releases. We are working on better documentation and
+ releases. There are also a few specific tests of extensions, as well
+ as a small but growing suite of individual Bugzilla bug regression tests.
+ We are working on better documentation and
structure for the tests.</item>
<label>What is a test result?</label>
<item>While most people view tests as having a simple boolean
@@ -152,12 +154,16 @@
<label>*Test.java/.class</label>
<item>As in 'ConformanceTest', 'PerformanceTest', etc.: a single,
automated test file designed to be run from the command line or
- from a testing harness.</item>
+ from a testing harness. This may be used in the future by
+ automated test discovery mechanisims.</item>
<label>*Testlet.java/.class</label>
<item>As in '<jump
href="apidocs/org/apache/qetest/xsl/StylesheetTestlet.html">StylesheetTestlet</jump>',
'PerformanceTestlet', etc.: a single,
automated testlet designed to be run from the command line or
from a testing harness. Testlets are generally focused on one
- or a very few test points, and usually are data-driven.</item>
+ or a very few test points, and usually are data-driven. A testlet
+ defines a single test case algorithim, and relies on the caller
+ (or *TestletDriver) to provide it with the data point(s) to use
+ in it's test, including gold comparison info.</item>
<label>*Datalet.java/.class</label>
<item>As in '<jump
href="apidocs/org/apache/qetest/xsl/StylesheetDatalet.html">StylesheetDatalet</jump>':
a single set of test data for
a Testlet to execute. Separating a specific set of data from the
@@ -211,7 +217,7 @@
<code>contrib-gold\foo\foo.out</code><br/><br/>
You could then run this test through the Conformance test driver like:<br/>
<code>cd xml-xalan\test</code><br/>
- <code>ContribTest.bat -category foo</code><br/>
+ <code>build contrib -Dqetest.category=foo</code><br/>
</p>
</s2>
1.4 +96 -23 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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- getstarted.xml 2001/03/02 00:50:09 1.3
+++ getstarted.xml 2001/08/21 19:58:31 1.4
@@ -3,12 +3,66 @@
<s1 title="Getting Started">
<ul>
+<li><link anchor="quickstart">Quick Start</link></li>
<li><link anchor="downloading">Downloading the code</link></li>
<li><link anchor="how-to-build">Building the Tests</link></li>
</ul>
+ <anchor name="quickstart"/>
+ <s2 title="Quick Start">
+ <note>This section assumes you are already familiar with building Xalan-J and
with Ant.</note>
+ <p>Set JAVA_HOME, and have your classes.zip or tools.jar in the CLASSPATH.</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)
+ </p>
+ <p><code>cd /builds </code>
+ <br/><code>checkout xml-xalan/test </code>
+ <br/><code>cd xml-xalan/test </code>
+ <br/><code>build jar </code> Build the test framework/harness and most
API/conf/etc. tests into <code>java/build/testxsl.jar </code>
+ <br/><code>build smoketest </code> Run the build Smoketest (includes a
selection of API tests and the conf tests); results in smoketest/
+ <br/><code>build conf </code> Run the StylesheetTestletDriver over the conf
dir; results in results-conf/
+ <br/><code>build conf -Dqetest.optionName=valueName -Dqetest.category=axes
</code> Run the StylesheetTestletDriver over the conf dir; passing options, and only
on the axes subdirectory
+ <br/><code>build api -DtestClass=TransformerAPITest </code> Run a single API
test; results in results-api/
+ <br/><code>build harness </code> Run the full set of individual API tests;
results in results-api/
+ </p>
+ <p><code>build extensions.classes </code> Compile the tests/extensions tests
+ <br/><code>build extensions </code> Run the tests/extensions tests
+ <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)
+ </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>
+ 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>
+ <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>
+ <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
+ 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
+ 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>
+ </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.
+ <br/><code>build api -DtestClass=TransformStateTest -Dapi.loggingLevel=30
</code> This runs
+ the org.apache.qetest.xalanj2.TransformStateTest with a lower loggingLevel (so
less is output).
+ Note that testClass is one of the few properties that is not prefixed.
+ </p>
+ </s2>
+
<anchor name="downloading"/>
- <s2 title="Downloading the code">
+ <s2 title="Downloading the tests">
<note>Since these tests are primarily to help developers test their
changes to Xalan source code, we don't currently provide prebuilt
builds of the test code. Most tests also require Xalan-J, even
@@ -23,57 +77,76 @@
(<jump href="http://xml.apache.org/cvs.html";>read-only access</jump> is
available to all), or:
<br/><br/>Get the latest <jump
href="http://xml.apache.org/from-cvs/xml-xalan/";>dev-snapshot</jump>:
these are .tar.gz files of the entire xml-xalan repository, including both the
- development sources and the test sources (they are just source, however, and
are not prebuilt).
+ 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.
</p>
</s2>
<anchor name="how-to-build"/>
<s2 title="Building the Tests">
- <p>This builds both the test harness/framework/etc. and the specific Java API
test files.
- It works similarly for DOS/Windows or your flavor of UNIX; in most cases *.sh
files are
- provided to match the *.bat files used here. Plans are underway to also
provide an
- Ant-based way to run tests, which is already cross-platform.</p>
- <p>1: Use CVS to check out the whole xml-xalan repository locally.
- <br/><code>e:\builds\xml-xalan</code></p>
- <p>2: Set an environment variable JARDIR to point to directory where you have
all applicable jars.
+ <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
+ 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>
+
+ <p>This assumes you already have a version of Xalan-J in
e:\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>
+ <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
+ framework, as well as the most common test drivers and API tests.
+ </p>
+ <p>The default way to build and run the tests assumes you have both the
xml-xalan/java
+ 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: Set an environment variable JARDIR to point to directory where
you have all applicable jars.
Delete testxsl.jar if present there.
<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</jump>)
- <br/><code>set JARDIR=e:\builds\myjars</code>
+ <br/><code>set JARDIR=e:\builds\myjars </code>
</p>
<p>3: Copy all product jars to the JARDIR</p>
<p>4: cd to the test directory and cleanup the tests.</p>
- <p><code>cd e:\builds\xml-xalan\test\java</code>
- <br/><code>build.bat clean</code>
+ <p><code>cd e:\builds\xml-xalan\test </code>
+ <br/><code>build.bat clean </code>
</p>
<p>5: Build the tests appropriate to your product.
<br/>Xalan-J 1.x:
- <br/><code>build.bat package.xalan</code>
+ <br/><code>build.bat package.xalan </code>
<br/>Xalan-J 2.x:
- <br/><code>build.bat package.xalan2</code> (<ref>or package.trax</ref>)
+ <br/><code>build.bat package.xalan2 </code> (<ref>or package.trax</ref>)
</p>
- <p>This will create <code>build\testxsl.jar</code>, which you should manually
copy
+ <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>.</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>
- <p>Note that ProcessorWrapper subclasses for XT and SAXON are currently checked
in
- both as .java source files and as precompiled .class files - the .class files
are
- merely copied into the jar by default, so you don't need the other processors
- on the classpath when building the jar. These classes aren't strictly necessary
- unless you're running tests with those flavors.</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>.
+ 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>
- <p>Building the Javadocs for the tests is done by <code>build.bat
javadocs</code>, and
+ <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,
+ 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
1.5 +20 -24 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.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- overview.xml 2001/03/02 00:50:09 1.4
+++ overview.xml 2001/08/21 19:58:31 1.5
@@ -13,7 +13,7 @@
<s2 title="Purpose of these tests">
<p>These tests are provided for Xalan contributors to evaluate the impact of
code changes.
Run the tests on the unchanged code, make the change and rebuild. Then run the
tests again
- and compare the results. Results should also be compared to the files in the
"-gold"
+ and compare the results. Results are automatically compared to the files in the
"-gold"
directory trees. Even though not all tests have "gold" files, it's still
valuable to run
the tests before and after a code change. That way you can at least ensure that
your changes didn't cause any regressions to the code before you check your
@@ -28,9 +28,7 @@
<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/java</code></label>
- <item>Top level for Java test automation</item>
- <label><code>xml-xalan/test/java/bin</code></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>)</item>
<label><code>xml-xalan/test/java/src</code></label>
@@ -44,9 +42,13 @@
<jump
href="apidocs/org/apache/qetest/trax/package-summary.html">org.apache.qetest.trax</jump><br/>
<jump
href="apidocs/org/apache/qetest/trax/dom/package-summary.html">org.apache.qetest.trax.dom</jump><br/>
<jump
href="apidocs/org/apache/qetest/trax/stream/package-summary.html">org.apache.qetest.trax.stream</jump><br/>
- <jump
href="apidocs/org/apache/qetest/xalanj1/package-summary.html">org.apache.qetest.xalanj1</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/>
<br/></item>
- <label><code>xml-xalan/test/tests</code></label><item>Top level for XSLT
stylesheet trees</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>
+ <label><code>xml-xalan/test/tests/conf-gold</code></label><item>Directory
tree of specific conformance testing stylesheets gold
+ output reference files (this tree should mirror the structure of
contrib)<br/></item>
<label><code>xml-xalan/test/tests/contrib</code></label><item>Directory tree
of user-contributed stylesheets</item>
<label><code>xml-xalan/test/tests/contrib-gold</code></label><item>Directory
tree of user-contributed stylesheets gold
output reference files (this tree should mirror the structure of
contrib)<br/></item>
@@ -58,23 +60,22 @@
<label></label><item>etc. - often the directory tree in the stylesheet area
will match the Java sources directory/package tree.</item>
<label><code>xml-xalan/test/tests/api-gold</code></label><item>Matching
Directory tree of gold files for Java API tests<br/></item>
- <label><code>xml-xalan/test/tests/extension</code></label><item>Directory
tree for stylesheets used in Xalan-specific extension tests</item>
-
<label><code>xml-xalan/test/tests/extension/xalanj1</code></label><item>Xalan-J 1.x
version-specific extension tests</item>
-
<label><code>xml-xalan/test/tests/extension/xalanj2</code></label><item>Xalan-J 2.x
version-specific extension tests</item>
- <label><code>xml-xalan/test/tests/extension-gold</code></label><item>Matching
Directory tree of gold files for Xalan-specific extension tests<br/></item>
- <label><code>xml-xalan/test/tests/...</code></label><item>More stylesheet
trees of testfiles to be added!
- (namely: tests/conf - Conformance tests to the XSLT spec)</item>
- <label><code>xml-xalan/test/tests/...-gold</code></label><item></item>
+ <label><code>xml-xalan/test/tests/extensions</code></label><item>Directory
tree for stylesheets used in Xalan-specific extension tests</item>
+ <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>
</gloss>
</s2>
<anchor name="test-map"/>
<s2 title="Listing of Java tests and drivers">
-<p>Java Test Drivers</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.
+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 are run through the test case in order.
The best example is <jump
href="apidocs/org/apache/qetest/xsl/StylesheetTestletDriver.html">StylesheetTestletDriver</jump></p>
<p>The Test Drivers rely on various Testlet implementations
to define the actual testing algorithim to apply to each xml.xsl
@@ -83,11 +84,11 @@
Examples include
<jump
href="apidocs/org/apache/qetest/xsl/StylesheetTestlet.html">StylesheetTestlet</jump>
and
<jump
href="apidocs/org/apache/qetest/xsl/PerformanceTestlet.html">PerformanceTestlet</jump></p>
-<p>The Testlets rely on ProcessorWrapper
+<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
-in different ProcessorWrapper "flavors" easily. Different
-ProcessorWrappers can process or transform in various ways, like
+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>
<p>The three levels of iteration, test algorithim, and
processor flavor are all independently changeable, so we can
@@ -102,6 +103,7 @@
<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>
<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>
@@ -169,12 +171,6 @@
<item>API coverage tests for javax.xml.transform.sax.TransformerHandler</item>
</gloss>
-<p>Java API tests for Xalan-J 1.x.</p>
-<gloss>
-<label>org.apache.qetest.xalanj1.ParamTest</label>
-<item>setting stylesheet parameters and verifies
-they're used correctly in a transform/process</item>
-</gloss>
<p>Some tests are ones that Xalan has not passed to date, but we know the
correct ("gold") result by analysis or by trying the test on other processors.
1.5 +17 -36 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.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- run.xml 2001/03/02 00:50:10 1.4
+++ run.xml 2001/08/21 19:58:31 1.5
@@ -21,34 +21,21 @@
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>
- <p>1: <link idref="getstarted" anchor="how-to-build">Build a fresh copy of
testxsl.jar.</link>
- <br/></p>
- <p>2: Set the JARDIR environment variable, and put <code>testxsl.jar</code> and
the other required JAR files in the JARDIR directory.<br/></p>
- <note>The tests will now default to using Xalan-J 2.x if JARDIR is not set,
- presuming that you have the tests in the same tree as xml-xalan\java (just like
- you get if you checkout the tree); you can use a JARDIR or not if you find it
convenient.</note>
- <p>3: cd xml-xalan\test<br/></p>
- <p>4: Run any of the convenience batch files (see below) or run java.exe with
the desired test class.<br/></p>
+ <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>
+ <p>You can either: use the Ant build.xml script; run a convenience batch file;
or execute java.exe yourself.</p>
+
<p>
- <code>conf.bat [<link anchor="test-options">options</link>]</code>
+ <code>build conf [<link anchor="test-options">Ant-prefixed
options</link>]</code>
<br/>(runs StylesheetTestletDriver over tests\conf test tree using the
default StylesheetTestlet)<br/><br/>
- <code>perf.bat [<link anchor="test-options">options</link>]</code>
+ <code>build perf [<link anchor="test-options">Ant-prefixed
options</link>]</code>
<br/>(runs StylesheetTestletDriver over tests\perf test tree using the
default PerformanceTestlet)<br/><br/>
- <code>traxapitest.bat TRAXAPITestClassName [<link
anchor="test-options">options</link>]</code>
- <br/>(runs TRAX interface tests with Xalan-J 2.x, equivalent to <br/>
- <code>runtest trax.TRAXAPITestClassName -load APITest.properties [<link
anchor="test-options">options</link>]</code><br/>
- For example:<code>traxapitest TransformerAPITest</code>
- <br/><br/>
-
- <code>xalanj1apitest.bat ParamTest [<link
anchor="test-options">options</link>]</code>
- <br/>(runs Xalan-J 1.x API tests, equivalent to <br/>
- <code>runtest xalanj1.ParamTest -load APITest.properties [<link
anchor="test-options">options</link>]</code><br/><br/>
- <code>runtest.bat end_pkg.AnyTestClassName [<link
anchor="test-options">options</link>]</code>
- <br/>(see batch file for comments) This is a generic way to run any tests -
- it assumes org.apache.qetest as the start of the package; you may
- need to provide the last part of the end_pkg name as well as the classname
- as well
- as providing any extra arguments for the test too.<br/>
+ <code>build api -DtestClass=TRAXAPITestClassName [<link
anchor="test-options">Ant-prefixed options</link>]</code>
+ <br/>(runs TRAX interface tests with Xalan-J 2.x<br/>
</p>
+ <p>Alternately: some convenience batch files are provided for the most common
+ tests - these simply turn around and call build.bat/.sh for you.<br/></p>
<p>Alternately: Run java.exe and the desired test class yourself:<br/></p>
<p>Note: the above batch and shell files, and the JARDIR environment variable,
are simply conveniences for running the tests. The Java API tests and test
drivers can
@@ -59,20 +46,10 @@
task that can run Xalan Tests and Testlets, so in the future both building
and running tests will mostly be done from an Ant buildfile, which is
cross-platform by default.</p>
- <p>Some tests are partially integrated into our Ant build.xml files, both for
the testing build.xml
- file as well as the one for Xalan-J 2.x itself. For example, to run
- the Xalan-J 2.x Minitest, you may now do:<br/>
- <code>cd xml-xalan\java</code><br/>
- <code>build minitest</code><br/>
- And this will build Xalan-J 2.x, then build a subset of the tests,
- and then run just the Minitest and print Pass (or Fail!).
- </p>
<note>Running tests with alternate JAXP parsers: all org.apache.qetest.trax.*
tests can be run with Xalan-J 2.x and any JAXP 1.1 compatible parser, like
crimson.jar. Be sure to manually set the appropriate system properties to use
your parser instead of xerces.jar, which is the default for Xalan-J.</note>
- <note>Most of the above batch files now accept a first argument '-crimson'
- to run the test with crimson.jar instead of xerces.jar automatically.</note>
</s2>
<anchor name="how-to-view-results"/>
@@ -85,8 +62,8 @@
<p>To 'pretty-print' results or produce reports, please use the
viewResults.xsl stylesheet and associated batch/shell files, like so:<br/>
<code>cd \xml-xalan\test</code><br/><br/>
- <code>runTest.bat MyTest -options blah <link
anchor="test-options-logfile">-logFile results\MyResults.xml</link></code><br/><br/>
- <code>viewResults.bat results\MyResults.xml results\MyPrettyResults.html
[options]</code><br/><br/>
+ <code>build conf -DoptionName=optionValue <link
anchor="test-options-logfile">-Dqetest.logFile
results/MyResults.xml</link></code><br/><br/>
+ <code>viewResults.bat results/MyResults.xml results\MyPrettyResults.html
[options]</code><br/><br/>
These options are passed to Xalan's command line to transform the
xml formatted output results into a nicer-looking html file. The most
common option would be <code>-param loggingLevel 99</code> to get
@@ -96,6 +73,10 @@
</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>
<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/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
