whitlock 2002/10/18 07:20:05
Modified: java/doc run.htm
Log:
Added unit test description
Revision Changes Path
1.2 +70 -2 xml-axis-wsif/java/doc/run.htm
Index: run.htm
===================================================================
RCS file: /home/cvs/xml-axis-wsif/java/doc/run.htm,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- run.htm 14 Oct 2002 16:47:53 -0000 1.1
+++ run.htm 18 Oct 2002 14:20:05 -0000 1.2
@@ -13,9 +13,77 @@
<h2>Tests</h2>
<p>
-TBW: general information about tests, junit and how to run them
+WSIF has a number of unit tests found in the tests directory. These use Junit
(currently Junit 3.7).
+WSIF unit tests are loosely themed and test function in multiple providers. For
instance
+jms.JmsTest tests jms:address, jms:property and jms:propertyValue tags across the
SoapJms,
+AxisJms and NativeJms providers. You can either run a specific unit test or run all
of them by
+running util.WSIFTestRunner. wsif.test.properties has
+wsif.test.components=ejb=on,jms=on,remotewsdl=on,jndi=on,fix=on,async=on
+which allows you to switch off areas across all unit tests. So because I rarely
change the EJB provider,
+I run with ejb=off so when I run WSIFTestRunner none of the EJB tests get run. This
can be dangerous
+and it is generally better to run all the unit tests. Individual unit tests can
call
+TestUtilities.areWeTesting("ejb") for instance. There are various listeners needed
to run the unit
+tests (JMS2HTTPBridge, JMSAsyncListener, NativeJMSRequestListener) and unit tests
automatically start
+and stop the listeners that they need. All the tests need to find WSDL and other
files on the
+local filesystem. This is done by looking for the WSIF src, samples and tests
directories under
+the directory specified by the wsif.path property in wsif.test.properties. So I
have wsif.path=c:\\wsif.
+The setup required to run the unit tests is based on the various providers being
used.
+</p>
+<p>
+For Soap and Axis over Http, find all files called DeploymentDescriptor.xml in the
samples and tests
+directories and deploy them to your favourite web server. The web server must be
running on your
+localhost using port 8080. In the future localhost:8080 should be a property loaded
from
+wsif.test.propeerties. The level of soap or axis used on your
+server does not have to be the same as the level used by WSIF. I use soap 2.2 on
tomcat so I issue
+java org.apache.soap.server.ServiceManagerClient
http://localhost:8080/soap/servlet/rpcrouter deploy
"samples\services\addressbook\DeploymentDescriptor.xml"
+</p>
+<p>
+There is no setup to do to run tests under the Java provider.
+</p>
+<p>
+To run tests using the EJB provider, ... todo ???
+</p>
+<p>
+There are three providers that are enabled for Jms : Soap, Axis and NativeJms.
Asynchronous support is
+currently only supported over Jms, so to test out async you need Jms. Obviously you
need a Jms
+implementation. WSIF uses JNDI to lookup Jms queues and queue connnection
factories. Topics are
+not supported at the moment. The batch files samples\wsifjmssetup.bat and
samples\wsifjmstidy.bat create
+and delete the JNDI definitions for the Jms queues and queue connection factory
needed to run the samples
+and some of the unit tests. I use IBM MQSeries as my Jms implementation so the
batch files
+samples\wsifmqsetup.bat and samples\wsifmqtidy.bat create and delete the MQSeries
queues needed to
+run the samples and some of the unit tests. The batch files
tests\wsiftestjmssetup.bat and tests\wsiftestmqsetup.bat create the
+JNDI definitions and the MQSeries queues needed to run the unit tests. No code in
WSIF or in the unit
+tests is MQ-specific, except for these mq batch files and WSIFJMSFinderForMq. The
unit tests also
+assume the local queue manager is being used. The unit tests also assume that the
JNDI database is on
+the filesystem in \JNDI-Directory.
+</p>
+<p>
+WSIF provides a JMS2HTTPBridge which takes soap messages from a Jms queue, routes
them to a url and sends
+the response message back to a replyTo queue. The JMS2HTTPBridge is intended as a
test tool only.
+So unit tests that test SoapJms and AxisJms start the JMS2HTTPBridge automatically.
NativeJms requests
+are served by the NativeJMSRequestListener which implements the backend service for
our unit tests.
+</p>
+<p>
+Specifying remotewsdl=on in wsif.test.components will enable the tests in the wsdl
package to be run. These
+tests test out loading wsdl from a url, from a jar file and test out imports. So
you need
+wsdl\ClassLoaderTest.jar on your classpath, and
http://localhost:8080/wsdl/AddressBook.wsdl needs
+to be available.
+</p>
+<p>
+The intention is for all unit tests to be run by WSIFTestRunner so everyone runs
them all automatically.
+Unfortunately there are a few tests which cannot be run in this way (or rather I
could not make them
+run automatically). An example of this is the translated.messages tests, because
these need to set the
+locale, and I could not reset the locale multiple times in the same test.
+</p>
+<p>
+The intention is for everyone to make sure that all the unit tests are kept working
all the time, so
+no regressions find their way in. If you add in new code (or even fixes) into WSIF,
please add in new
+unit tests, or extend existing tests to cover the new code you've added. Otherwise
tomorrow someone
+may unknowingly break your code. If you add in new unit tests please add them to
WSIFTestRunner so
+that everyone will automatically run them as well. I guess when you make a change
that requires a
+service to be redeployed or a queue definition to be added or changed, please
notify everyone on
+axis-dev so that everyone can update their setup.
</p>
-
<h2>Samples</h2>
<p>
