Is this the genesis of buildUnit? :-)
Conor
[EMAIL PROTECTED] wrote:
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? -- 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/28/02 01:07 PM Please respond to "Ant Developers List"
----- Original Message ----- From: "Conor MacNeill" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Monday, May 27, 2002 7:03 PM Subject: Re: Ant test framework
[EMAIL PROTECTED] wrote:
This is part of an email conversation between Conor and myself about getting the build file test framework available as another deliverable
of
ant.
In Maven, we've written several project specific tasks that need to be tested on a regular basis, and rather than subsume the source code from Ant, we'd much prefer the 'Ant Test Framework' to be available as a jar file so that other projects can specify it as a test dependency, and
use
it.
So the proposal is that for Ant 1.6 and beyond the test classes needed
to
test build files be packaged up as another jar and made a deliverable
like
the optional jar is.
Votes: +1/-1/+0/-0?
I'm willing to make a new build file for ant to build the test
framework
and package it as a jar (i.e. +1 from a non-committer).
As I said, Steve has been looking at this. I can't remember the latest thinking. I've looked a bit further just now and I think that perhaps the easiest thing is just to move BuildFileTest into the main source tree (and hence ant.jar) without moving it in its package namespace. The Ant tests would continue to function as is and task developers would not have to copy and paste code to access test facilities.
I think Mageshe's concept, which I was happy with, was to have a separate jar, number it ant-test-framework1.5.jar, or the like, and make *no* guarantees about forward/backwards compatibility.
If we publish the tests as part of the core API, then it is frozen for eternal support.
seems to me that there is something odd about the fact that we have to code our build file tests in java. Surely we should be able to do a lot of them (all the ones where we make assertions about the state of properties, or expect assertions), using a more declarative XML style...
steve
-- 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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
