One thing I would really like to have is the ability to specify an endpoint for any "functional" test. I'm classifying tests in three categories:
UNIT tests : in-proc, uses local server if any FUNCTIONAL tests : uses arbitrary server NETWORK tests : endpoints are entirely external (xmethods, etc) As it stands our functional test process does this (after building): 1) Start up HTTP and TCP based servers 2) Deploy everything 3) Run everything 4) Undeploy everything 5) Shut down servers I'd like to see this instead: ant -DendpointURL=http://myhost/axis (I'm guessing we just specify to "/axis" here so that we can use the "services/ServiceName" pattern in the tests) 1) IF endpoint is not specified, start up HTTP server (SimpleAxisServer) and use default URLs 2) FOREACH test 2.1) Deploy to endpoint URL 2.2) Run test 2.3) Undeploy 3) IF we started up SimpleAxisServer, shut it down Then the couple of tests which use the TCP server would be responsible for starting it up/shutting it down themselves. The main gain here would be the ability to run the set of functional tests against a servlet-based endpoint, which we do not currently do. In general the restructuring ideas look great! Still looking over the details during the slow parts of the meeting here... :) --Glen ----- Original Message ----- From: "Steve Loughran" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 10, 2002 9:42 PM Subject: Re: Proposal for Test and Samples Changes > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, June 10, 2002 8:30 AM > Subject: Proposal for Test and Samples Changes > > > > All: > > > > Attached is an HTML document with a little more description of my proposed > > changes to the way that Tests and Samples are handled in AXIS. Please > > note, most of this is what I have already done, and functioning with no > > regressions to function. > > > > Please give me any feedback you feel appropriate, especially telling me > > where I need more detail / more description. I will try to get a "sample > > implementation" document together over the next few days so that you can > > better visualize the process flow. > > > My goals for a rework of the framework are to > -eliminate duplicate declarations (eg. repeated classpath decls) > -make the tests runnable standalone, if that makes it easier to dev and test > a single problem > -make it easy to add new tasks > -reduce future maintenance requirements > > To reduce duplication, all common things like classpaths and the like can be > declared in common XML fragment files and then pulled in to each test build > file: > > <?xml version="1.0" encoding="UTF-8" ?> > <!DOCTYPE project [ > <!ENTITY properties SYSTEM "file:../properties.xml"> > <!ENTITY taskdef SYSTEM "file:../taskdef.xml"> > <!ENTITY targets SYSTEM "file:../targets.xml"> > ]> > > <project name="Web App Deployment" default="default" basedir="."> > <description> > deploy the Web application > </description> > > <!-- BEGIN TOPLEVEL DECLARATIONS --> > <!-- include the xml file reference declared earlier --> > &properties; > &taskdef; > &targets; > > ...so > > nb, targets.xml has : > <target name="noop"> > <echo>no-op in ${ant.project.name}</echo> > </target> > > -useful for debug, while properties.xml has > > <property name="root.dir" location="${basedir}"/> > <property name="masterbuild.dir" location="${root.dir}/.."/> > <property file="${masterbuild.dir}/build.properties"/> > > so it works out where it is and then pulls in main properties files from the > base directory of the project. Build files further down the tree would need > to be set up with <property name="masterbuild.dir" location="../../.." /> > before the &properties; declaration for it all to work. > > With this layout, you dont need to run everything from a container build > file; standalone works just nicely. The toplevel build file just invokes the > sub projects, implementing a dependency graph by having the antcalls inside > their own depends graph. > > here are some of the targets that hand down > > <target name="do-common"> > <ant dir="common" target="${target}" > inheritAll="false> > </target> > > > <target name="do-tools" > depends="do-common,do-index,do-common-test"> > <ant dir="tools" target="${target}" > inheritAll="false> > </target> > > <target name="do-webapp" > depends="do-common,do-index,do-common-test"> > <ant dir="webapp" target="${target}" > inheritAll="false> > </target> > > <target name="do-all" depends="do-tools,do-webapp"/> > > and here is an example entry point, which hands off to the graph of build > file dependencies, the target we want done. > > <target name="clean" > description="clean up"> > <antcall target="do-all"> > <param name="target" value="clean"/> > </antcall> > </target> > > > So: <ant> is called in the directory of the target build file, not relative > to the local directory. No references are passed down, other than command > line -D stuff. > > The key is the XML includes files: once you have those each build file is > standalone, but shared declarations with all the others. To add a new > library, you do it one place, Same for a new task declaration. > > -steve > > >
