Stefan,
That sounds like exactly what I'm looking for. Only there's one big problem.
I'm behind an authenticating HTTP proxy and I can't seem to get my svn client
to get through it. Our in office proxy has traditionally caused me such
problems and I faced this about a month ago when I was trying to retrieve the
FOP trunk. I somehow got it to work then but I'm not sure how. I've never
used svn before (asides from my clumsily fumbling and actually getting the
FOP trunk). I read somewhere that certain proxies don't handle the extended
web-dav commands well or pass them through the way they should. I'm not sure
if that's my problem or not. I also read that one solution involved either
switching from http to https (or the other way around, I'm not sure). Could
you or someone knowledgeable help me get my svn client to retrueve the Ant
trunk so I can play with Antunit? Thanx!
---------------------------------------------------
Clifton C. Craig, Software Engineer
Intelligent Computer Systems - A Division of GBG
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Monday 23 January 2006 11:58 pm, Stefan Bodewig wrote:
> On Mon, 23 Jan 2006, Ninju Bohra <[EMAIL PROTECTED]> wrote:
> > I too created test cases for my build files (actually they are build
> > files for testing my custom tasks, but they are still build files).
> >
> > I used the BuildFileTest class as the base class (that my JUnit
> > classes extended from).
>
> This is the traditional way Ant used itself, but this is going to be
> replaced by AntUnit step by step. The difference is that you don't
> write a Java class at all.
>
> Say I want to test the <touch> task and validate it creates a file, I
> write a build file:
>
> <project xmlns:au="antlib:org.apache.ant.antunit">
> <property name="foo" value="foo"/>
>
> <target name="tearDown">
> <delete file="${foo}" quiet="true"/>
> </target>
>
> <target name="testTouchCreatesFile">
> <au:assertFileDoesntExist name="${foo}"/>
> <touch file="${foo}"/>
> <au:assertFileExists name="${foo}"/>
> </target>
> </project>
>
> > The class provided some convience methods for reading the build.xml,
> > initializing the project, and accessing property and log output
> > (very useful when verified build behavior).
>
> AntUnit provides a generic <assert> task (with a nested condition) as
> well as a bunch of macrodef'ed asserts and
>
> > but I never quite thought of "testing" a build script with unit
> > tests (it seems a bit recursive as you would need a build script to
> > invoke the build you are testing...)
>
> an <antunit> task to do just that. The task takes a bunch of build
> files and runs the targets whose names start with "test", with special
> handling for targets names setUp and tearDown. And it provides for
> test listeners.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
