Ok, where to from here....do you want someone to come up with some tasks
and go from there? Or should we discuss the implementation details here
first?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
"Steve
Loughran" To: "Ant Developers List" <[EMAIL
PROTECTED]>
<[EMAIL PROTECTED] cc:
n.com> Subject: Re: Ant test framework
05/29/02 02:57
AM
Please respond
to "Ant
Developers
List"
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Monday, May 27, 2002 8:58 PM
Subject: Re: Ant test framework
>
> Steve,
>
> a build file test framework as a task?, e.g. the asserts are nested
> elements..... so for the AvailableTest:
>
> <buildfiletest buildFile="src/etc/testcases/taskdefs/available.xml">
> <target name="test1">
> <exception text="required argument not specified" />
> </target>
> <target name="test2">
> <exception text="required argument not specified" />
> </target>
> <target name="test3">
> <exception text="required argument not specified" />
> </target>
> <target name="test4">
> <property name="test" value"${null}"/>
> </target>
> </buildfiletest>
>
> is this what you mean?
yep. That is exactly what I mean.
If you look at some of the more recent test cases I've been doing, I've
been
putting more and more of the logic into the task itself. For almsot all but
exception catching. you can use <condition> and <fail> to validate task
behaviour.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
