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]
