You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by se...@apache.org on 2002/08/07 19:50:45 UTC
cvs commit: xml-axis/java/docs AxisTestRedesign.html
seibert 2002/08/07 10:50:45
Modified: java/docs AxisTestRedesign.html
Log:
Okay, here is the long version:
I moved the following targets from buildTest.xml into xmls/targets.xml:
<target name="start-functional-test-tcp-server" if="junit.present">
<target name="start-functional-test-http-server" if="junit.present">
<target name="stop-functional-test-http-server" if="junit.present" depends="stop-signature-signing-and-verification">
<target name="stop-functional-test-http-server-secure" if="junit.present" depends="stop-signature-signing-and-verification">
<target name="start-signature-signing-and-verification" if="security.present">
<target name="stop-signature-signing-and-verification" if="security.present">
This lets me start the server from any given file, without a LOT of repetitive code. I then created:
<target name="component-junit-functional-prepare" if="junit.present">
<target name="component-junit-functional" if="junit.present" depends="component-junit-functional-prepare,start-signature-signing-and-verification">
which are just "component compliant" (i.e. genericized" versions of the original "junit-functional-prepare" and
"junit-functional" targets. These handle the creation of the deploy.xml and undeploy.xml properties with the services
to deploy for each test, as well as execing the specific tests themselves.
I created a nasty thing called:
<target name="execute-Component" depends="setenv" >
which, coincidentally, is the action peice for executing the test of any given component. It will look similar to "functional-tests". Here is how some given componentized test "x" which is in test/y/x, is invoked:
In the file test/y/x/buildComponent.xml, there are two properties defined:
1) axis.home is REDEFINED to be the depth of the test. So for test/y/x, axis.home = "../../.."
2) componentName is defined to be the realtive path structure "test/y/x"
the component- targets use these property variables to gather up files, determine tests to exec, and operate.
In addition to these, there is one more property "extraServices" which can be defined. This is to support some given test needing a service deployed which is NOT self-contained. The primary (and only, so far) example of this is the test/wsdl/multithread test. It needs the Address Sample service deployed prior to running, but the samples/addr tree is just about as disjoint as you can possibly get from the test/wsdl/multithread tree. So I created an optional placeholder to accomdate this oddity.
There is only one major assumption made:
"This test, and everything NEEDED by this test, is found in some path structure relative to axis.home."
This keeps the dependancy checking down. In english, this means that if test/y/x need something from xml-axis, when it, the test, lives in xml-axis/java, you will need to hack a LOT of files to re-define axis.home as xml-axis instead of as xml-axis/java.
Does this make sense?
Revision Changes Path
1.3 +15 -19 xml-axis/java/docs/AxisTestRedesign.html
Index: AxisTestRedesign.html
===================================================================
RCS file: /home/cvs/xml-axis/java/docs/AxisTestRedesign.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
Binary files /tmp/cvsNRxfTO and /tmp/cvs9ScKlM differ
Re: cvs commit: xml-axis/java/docs AxisTestRedesign.html
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: <se...@apache.org>
To: <xm...@apache.org>
Sent: Wednesday, August 07, 2002 10:50 AM
Subject: cvs commit: xml-axis/java/docs AxisTestRedesign.html
> seibert 2002/08/07 10:50:45
>
> Modified: java/docs AxisTestRedesign.html
> Log:
> Okay, here is the long version:
>
> I moved the following targets from buildTest.xml into xmls/targets.xml:
>
> <target name="start-functional-test-tcp-server" if="junit.present">
> <target name="start-functional-test-http-server" if="junit.present">
> <target name="stop-functional-test-http-server" if="junit.present"
depends="stop-signature-signing-and-verification">
> <target name="stop-functional-test-http-server-secure"
if="junit.present" depends="stop-signature-signing-and-verification">
> <target name="start-signature-signing-and-verification"
if="security.present">
> <target name="stop-signature-signing-and-verification"
if="security.present">
>
> This lets me start the server from any given file, without a LOT of
repetitive code.
slick.
>I then created:
>
> <target name="component-junit-functional-prepare" if="junit.present">
> <target name="component-junit-functional" if="junit.present"
depends="component-junit-functional-prepare,start-signature-signing-and-veri
fication">
>
> which are just "component compliant" (i.e. genericized" versions of the
original "junit-functional-prepare" and
> "junit-functional" targets. These handle the creation of the deploy.xml
and undeploy.xml properties with the services
> to deploy for each test, as well as execing the specific tests
themselves.
>
> I created a nasty thing called:
> <target name="execute-Component" depends="setenv" >
>
> which, coincidentally, is the action peice for executing the test of any
given component. It will look similar to "functional-tests". Here is how
some given componentized test "x" which is in test/y/x, is invoked:
>
> In the file test/y/x/buildComponent.xml, there are two properties
defined:
> 1) axis.home is REDEFINED to be the depth of the test. So for
test/y/x, axis.home = "../../.."
> 2) componentName is defined to be the realtive path structure
"test/y/x"
>
ok.
I still want to bring the http unit tests in to the framework fully, which
(currently) means running only when there is a real app server running
somewhere. Maybe we can use the <http> condition to probe for a file like
axis/index.html as a test to see what kind of server is up.
> There is only one major assumption made:
> "This test, and everything NEEDED by this test, is found in some path
structure relative to axis.home."
>
> This keeps the dependancy checking down. In english, this means that if
test/y/x need something from xml-axis, when it, the test, lives in
xml-axis/java, you will need to hack a LOT of files to re-define axis.home
as xml-axis instead of as xml-axis/java.
I see.
You know, we may want to have another property, axis.cvs.base that is
defined as axis.home/.., so that people can do cvs base relative stuff by
redefining this property. Of course, there is no guarantee that stuff
relative to axis base exists; I had one box that only had xml-axis/java
checked out into a directory called axis; that completely broke with the old
build, but will work now.
-Steve