[Webtest] Building suites and removing duplication

Fri, 17 May 2002 13:12:41 -0400

Has the <init> stuff made it into the DBUnit destribution?  I would love to
see it there!

I like this method, it is much better then my method of doing it.  Now I
just need some basic javascript support!

Eric

-----Original Message-----
From: webtest-admin@gate.canoo.com
[mailto:webtest-admin@gate.canoo.com]On Behalf Of Ben Cox
Sent: Friday, May 17, 2002 12:31 PM
To: webtest@gate.canoo.com
Subject: Re: [Webtest] Building suites and removing duplication

I think this approach is on the right track.  What Tim and I did was
defined a buildfile called TestSuite.xml at the top-level directory of
our test tree.  That contained the following:

<target name="runTest" depends="initDb">
   <echo>
       Executing target: {$targetName} in build file ${basedir}/{$filename}
   </echo>
</target>

The initDb target, by the way, is a DBUnit target (Tim and I created a
DBUnit ant task) that populates the database lookup tables.  Then, a
<dbunit> task is included in most tests before the <testSpec> task that
sets the database to a known state for the test.
The ant files referred to in the "testSuite" target are all in
subdirectories, as you can probably tell.  In each of those appears
something resembling the following:

<target name="testSuite" depends="loginTest, addClient, addToolmaker, ...">
   <echo>Finished testSuite for AddDataViaAdmin.</echo>
</target>

The ... indicates that all of your targets from that buildfile get put
in there.  Basically, the testSuite for a given file is run with the
command line:

   ant -buildfile=admin/AddDataViaAdmin.xml testSuite

the testSuite for the whole system is run with the command line:

   ant -buildfile=TestSuite.xml testSuite

and an individual test can be run with a more complicated command line
For example, to run the addClient test target from the
AddDataViaAdmin.xml file:

   ant -buildfile=TestSuite.xml runtest
-Dfilename=admin/AddDataViaAdmin.xml -DtargetName=addClient

Though this command line seems a touch unwieldy, in practice we found it
quite usable.

Hope that helps,

   Ben Cox

Johannes Link wrote:
> Hi Dierk,
>
>
>>BTW: you don't need to do the entity def in a dtd. You can
>>extract whole xml nodes in external files.
>
>
> Do you refer to the SYSTEM command in the DTD or something else?
>
>
>>If that does not address your problem:
>>How would a WebTest look like, where your problem is solved?
>
>
> I could imagine something like:
> <defstep name="mytask">
>    <param name="param1"/>
>    <invoke ...>
>    <verify ... text=${param1}/>
> </stepdef>
>
> used as:
> <callstep name="mytask">
>    <param name="param" value="value1">
> </callstep>
>
> However I'm not sure if this really helps. Alternatively one could have
> another xslt step which transforms our xml (without duplication etc.) into
a
> proper webtest xml file. But well, I'm not very enthusiastic about this
"meta
> programming with xml/xslt" since it is very difficult not to loose control
and
> overview when faced with several transformations in a row.
>
> Johannes
>

_______________________________________________
WebTest mailing list
WebTest@lists.canoo.com
http://lists.canoo.com/mailman/listinfo/webtest