[Webtest] Building suites and removing duplication

[Ben Cox]

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>

<target name="testSuite" depends="initDb">
   <ant antfile="admin/AddDataViaAdmin.xml"/>
   <ant antfile="build/EditToolData.xml"/>
   ...
</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
>