You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/11/02 22:36:37 UTC

Re: AntUnit

On Wed, 2 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:

> Again, I am anxious to get all of Ant's tests migrated
> to Antunit,

I'm not sure whether "all" is the best goal, but a lot of them can be.
Looking over the tests I've added over the past weeks, I really only
needed antunit's capabilities.

> but haven't been able to get my head around how to integrate them
> organization-wise. Circular dependencies and all.  Would build.xml
> build antunit, then use it?

After bootstrapping, yes.  There is no circular dependency since you
don't need antunit to build Ant, only to test it.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Martijn Kruithof <jk...@apache.org>.
Matt Benson wrote:

>--- Stefan Bodewig <bo...@apache.org> wrote:
>  
>
>>
>>After bootstrapping, yes.  There is no circular
>>dependency since you
>>don't need antunit to build Ant, only to test it.
>>    
>>
>
>How does Ant know where to get antunit?  From SVN? 
>Using what? The svn antlib?  How does Ant know where
>to get _that_? ;) I wonder if the maven2 tasks could
>be helpful here...
>
>-Matt
>  
>
What would be the reason to not move antunit to the core ant distribution,
as soon as we start using antunit from the core ant distribution, even 
if it is
only for testing, the task should not be in the sandbox, and I would say
we have better candidates to be moved to separate libraries.
(for instance all scm tasks)
Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Martijn Kruithof <jk...@apache.org>.
Matt Benson wrote:

>--- Stefan Bodewig <bo...@apache.org> wrote:
>
>  
>
>>Does it need to?  Ant doesn't know where to get
>>junit either.  Simply
>>make the presence of antunit a requirement just as
>>we require junit
>>today.
>>    
>>
>
>So it could be fetched in some way similar to that
>done by fetch.xml ...
>  
>

The current ant tests can be run without performing a fetch, the junit 
jar file is included in the source distribution (and svn tree) of ant. 
Fetching anything beyond the svn tree is not necessary to compile the 
core parts of and ant, and testing ant.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Steve Loughran <st...@apache.org>.
Kev Jackson wrote:
> 
>>
>> I think the using / maintaining by ourselves is more of a chicken and 
>> egg problem
>> - We do not really need it for our "outside ant" activities
>> - We cannot really use it for our "inside ant" activities as it is in 
>> the sandbox.
>> - We do not maintain it as we do not use it, and it is in the sandbox.
>>
>> I am in favour of
>> 1) moving antunit part of the core
>> 2) start using this testing strategy by the tests of core.
>>
>> We sould only do 1 if we want to do 2 (and I think we want to do 2)
>> And we should only do 2 after we have done 1.
>>
>> If we start doing 2 I am sure there will be enough committers.
> 
> 
> If there's a consensus on actually using antunit to test ant, then it 
> would have to be moved out of the Sandbox.  I haven't really looked at 
> antunit enough to see why it's more appropriate than junit for writing 
> ant tests, but because of the name, I'm assuming that it is!  As it is 
> designed as a testing compliment to Ant, I would think that it should be 
> promoted out of the sandbox as soon as possible and that the 'official' 
> testing strategy of Ant would be to use the antunit functionality.

I've been looking at it this weekend, as I write the tests for the http 
antlib. Its pretty slick, though I would have to use it a bit more to be 
sure. I'm particularly curious about how I'm going to debug stuff 
running under it.


1. I like au: being in its own namespace/antlib; it should stay that way 
even if it is part of the core codebase.

2. we need to think how we will have multiple antlibs under that 
codebase, all with their own build

maybe a subdir antlib with standard targets in each antlib underneath, 
so we can tell all of them to install into a standard dest dir on the 
ant classpath on demand:

<subant target ="install" >
   <fileset dir="antlib" includes="*/build.xml">
</subant>

3. we also need to think about inter-antlib dependencies. I will need 
antlib to test my antlib.

-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Kev Jackson <ke...@it.fts-vn.com>.
>
> I think the using / maintaining by ourselves is more of a chicken and 
> egg problem
> - We do not really need it for our "outside ant" activities
> - We cannot really use it for our "inside ant" activities as it is in 
> the sandbox.
> - We do not maintain it as we do not use it, and it is in the sandbox.
>
> I am in favour of
> 1) moving antunit part of the core
> 2) start using this testing strategy by the tests of core.
>
> We sould only do 1 if we want to do 2 (and I think we want to do 2)
> And we should only do 2 after we have done 1.
>
> If we start doing 2 I am sure there will be enough committers.

If there's a consensus on actually using antunit to test ant, then it 
would have to be moved out of the Sandbox.  I haven't really looked at 
antunit enough to see why it's more appropriate than junit for writing 
ant tests, but because of the name, I'm assuming that it is!  As it is 
designed as a testing compliment to Ant, I would think that it should be 
promoted out of the sandbox as soon as possible and that the 'official' 
testing strategy of Ant would be to use the antunit functionality.

I think a vote is in order as I doubt people will move towards writing 
antunit tests without at least a little comfort that their effort won't 
go down the pipes with antunit being dropped as it stayed in the sandbox 
too long.

2p

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 7 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:

> The current version of AntUnit probably has 80% or
> better of the total test functionality.  I think our
> tests rely less and less on log messages and more on
> results, etc.  Log contents are probably the biggest
> thing missing from au...

Take a second look 8-)

<au:logContains> and <au:logDoesntContain> are there and work.  What
doesn't work right now is capturing System.err/.out reliably because
of the bug in Ant's core Jeffrey talked about (Ant losing track of the
currently executing task because Definer uses perform instead of
execute).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Dale Anson <da...@grafidog.com>.

Stefan Bodewig wrote:

>  
>
>>Might just need an "add(AntUnit)" method in AntUnit itself.
>>    
>>
>
>Interesting idea.
>
>  
>
>>3. a way to disable individual tests or disable entire suites.
>>    
>>
>
>In JUnit I tend to do so by simply changing the name of the method
>(prefix with no) and even in NUnit which supports an [Ignore]
>attribute to disable text I find myself commenting out the [Test]
>attribute more often than adding the ignore one.  But that could be
>me.
>
>I wouldn't want to add any new attributes to <target> and would want
>to keep all information inside of the build file under test instead of
>the antunit task.  Given those constraints, I don't see how we could
>add an ignore feature.  Any ideas?
>
>Stefan
>
>  
>
Sorry, I wasn't real clear when I said "disable individual tests".  I 
was meaning at a file level, not at a target level.  Something like this:

    <property name="do_full_test" value="true"/>
    <property name="do_quick_test" value="false"/>
    <au:antunit name="testgroup1" enabled="${do_full_test}">
       <fileset .../>
       <au:listener/>
    </au:antunit>
    <au:antunit name="testgroup2" enabled="${do_quick_test}">
       <fileset .../>
       <au:listener/>
    </au:antunit>

Dale


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 07 Nov 2005, Dale Anson <da...@grafidog.com> wrote:

> There are a few things I'd like to see added to AntUnit:
> 
> 1. better reporting, probably just need a more involved
> AntUnitListener.

Yes, this should be doable.  The PlainListener really only is a first
start so I could see the results and validate the design.

> 2. support for a "suite" concept, that is, a way to group tests
> beyond filesets.

which should be ResourceCollections soon.

> Might just need an "add(AntUnit)" method in AntUnit itself.

Interesting idea.

> Include reporting per suite. Having a "name" attribute for each
> antunit would also be useful for reporting.

True.

> 3. a way to disable individual tests or disable entire suites.

In JUnit I tend to do so by simply changing the name of the method
(prefix with no) and even in NUnit which supports an [Ignore]
attribute to disable text I find myself commenting out the [Test]
attribute more often than adding the ignore one.  But that could be
me.

I wouldn't want to add any new attributes to <target> and would want
to keep all information inside of the build file under test instead of
the antunit task.  Given those constraints, I don't see how we could
add an ignore feature.  Any ideas?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Dale Anson <da...@grafidog.com>.
As I mentioned in another thread, this approach to unit testing for Ant 
is much easier than junit testing.  The concept is similar, but there is 
no need to write Java code for tests.  The tests are in build files, 
several layers of indirection are avoided, and anyone who can write a 
build file can write a test.  Think of all the build file snippets from 
the user list that people submit with problems that could easily be 
turned into unit tests.  Even better, each of these tests becomes a 
working example that could be linked to the Ant documentation.  I see 
this as a big win.

I have written a similar system as part of Antelope, but I think 
Stefan's implementation is cleaner.  There are a few things I'd like to 
see added to AntUnit:

1. better reporting, probably just need a more involved AntUnitListener.
2. support for a "suite" concept, that is, a way to group tests beyond 
filesets.  Might just need an "add(AntUnit)" method in AntUnit itself.  
Include reporting per suite. Having a "name" attribute for each antunit 
would also be useful for reporting.
3. a way to disable individual tests or disable entire suites.

Dale


Matt Benson wrote:

>--- Martijn Kruithof <jm...@kruithof.xs4all.nl> wrote:
>
>  
>
>>Stefan Bodewig wrote:
>>
>>    
>>
>>>I'd not be opposed against making antunit part of
>>>      
>>>
>>the core, but so far
>>    
>>
>>>it hasn't attracted enough committers to even leave
>>>      
>>>
>>the sandbox.  And
>>    
>>
>>>the six months probation time is over, BTW.
>>>      
>>>
>
>FWIW, my feeling is that AntUnit _is_ where we (at
>least I) want to get to, and I would desire that it be
>exempted from the probation period on those grounds. 
>:)
>
>  
>
>>>Stefan
>>> 
>>>
>>>      
>>>
>>I think the using / maintaining by ourselves is more
>>of a chicken and 
>>egg problem
>>- We do not really need it for our "outside ant"
>>activities
>>- We cannot really use it for our "inside ant"
>>activities as it is in 
>>the sandbox.
>>- We do not maintain it as we do not use it, and it
>>is in the sandbox.
>>    
>>
>
>I agree 100% here.  Ant is the place to prove AntUnit.
> So do we make a build of AntUnit and include in
>lib/optional in Ant core HEAD? (on another thread,
>Martijn mentioned that we bundle a junit jar and
>would/should handle AntUnit similarly; agreed, but
>fetch.xml does have the capability to fetch the junit
>jar as well)
>
>  
>
>>I am in favour of
>>1) moving antunit part of the core
>>    
>>
>
>+0... we should be able to move the artifact to
>lib/optional and make the tests conditional as w/
>current... obviously we should also make the AntUnit
>test path in build.xml separate from the JUnit path,
>so we can slowly move tests from the latter to the
>former.
>
>  
>
>>2) start using this testing strategy by the tests of
>>core.
>>
>>We sould only do 1 if we want to do 2 (and I think
>>we want to do 2)
>>    
>>
>
>I know I do.  Basically more and more of us _have_
>been using the au strategy, just without the
>syntactic/semantic sugar it provides.  :)
>
>  
>
>>And we should only do 2 after we have done 1.
>>
>>If we start doing 2 I am sure there will be enough
>>committers.
>>
>>    
>>
>The current version of AntUnit probably has 80% or
>better of the total test functionality.  I think our
>tests rely less and less on log messages and more on
>results, etc.  Log contents are probably the biggest
>thing missing from au... we could write these, or just
>change the logic of those tests (this decision might
>require a vote).  But my point is that "enough
>committers" shouldn't amount to much.  :)
>
>-Matt
>
>  
>
>>Martijn
>>
>>
>>    
>>
>---------------------------------------------------------------------
>  
>
>>To unsubscribe, e-mail:
>>dev-unsubscribe@ant.apache.org
>>For additional commands, e-mail:
>>dev-help@ant.apache.org
>>
>>
>>    
>>
>
>
>
>	
>		
>__________________________________ 
>Yahoo! Mail - PC Magazine Editors' Choice 2005 
>http://mail.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Matt Benson <gu...@yahoo.com>.
--- Martijn Kruithof <jm...@kruithof.xs4all.nl> wrote:

> Stefan Bodewig wrote:
> 
> >I'd not be opposed against making antunit part of
> the core, but so far
> >it hasn't attracted enough committers to even leave
> the sandbox.  And
> >the six months probation time is over, BTW.

FWIW, my feeling is that AntUnit _is_ where we (at
least I) want to get to, and I would desire that it be
exempted from the probation period on those grounds. 
:)

> >
> >Stefan
> >  
> >
> 
> I think the using / maintaining by ourselves is more
> of a chicken and 
> egg problem
> - We do not really need it for our "outside ant"
> activities
> - We cannot really use it for our "inside ant"
> activities as it is in 
> the sandbox.
> - We do not maintain it as we do not use it, and it
> is in the sandbox.

I agree 100% here.  Ant is the place to prove AntUnit.
 So do we make a build of AntUnit and include in
lib/optional in Ant core HEAD? (on another thread,
Martijn mentioned that we bundle a junit jar and
would/should handle AntUnit similarly; agreed, but
fetch.xml does have the capability to fetch the junit
jar as well)

> 
> I am in favour of
> 1) moving antunit part of the core

+0... we should be able to move the artifact to
lib/optional and make the tests conditional as w/
current... obviously we should also make the AntUnit
test path in build.xml separate from the JUnit path,
so we can slowly move tests from the latter to the
former.

> 2) start using this testing strategy by the tests of
> core.
> 
> We sould only do 1 if we want to do 2 (and I think
> we want to do 2)

I know I do.  Basically more and more of us _have_
been using the au strategy, just without the
syntactic/semantic sugar it provides.  :)

> And we should only do 2 after we have done 1.
> 
> If we start doing 2 I am sure there will be enough
> committers.
> 
The current version of AntUnit probably has 80% or
better of the total test functionality.  I think our
tests rely less and less on log messages and more on
results, etc.  Log contents are probably the biggest
thing missing from au... we could write these, or just
change the logic of those tests (this decision might
require a vote).  But my point is that "enough
committers" shouldn't amount to much.  :)

-Matt

> Martijn
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Martijn Kruithof <jm...@kruithof.xs4all.nl>.
Stefan Bodewig wrote:

>I'd not be opposed against making antunit part of the core, but so far
>it hasn't attracted enough committers to even leave the sandbox.  And
>the six months probation time is over, BTW.
>
>Stefan
>  
>

I think the using / maintaining by ourselves is more of a chicken and 
egg problem
- We do not really need it for our "outside ant" activities
- We cannot really use it for our "inside ant" activities as it is in 
the sandbox.
- We do not maintain it as we do not use it, and it is in the sandbox.

I am in favour of
1) moving antunit part of the core
2) start using this testing strategy by the tests of core.

We sould only do 1 if we want to do 2 (and I think we want to do 2)
And we should only do 2 after we have done 1.

If we start doing 2 I am sure there will be enough committers.

Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 4 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:

>> Simply make the presence of antunit a requirement just as we
>> require junit today.
> 
> So it could be fetched in some way similar to that
> done by fetch.xml ...

I was more thinking along the lines of including a jar with our source
tree as well.

I'd not be opposed against making antunit part of the core, but so far
it hasn't attracted enough committers to even leave the sandbox.  And
the six months probation time is over, BTW.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:

> On Wed, 2 Nov 2005, Matt Benson
> <gu...@yahoo.com> wrote:
> 
> > How does Ant know where to get antunit?  From SVN?
> 
> 
> Does it need to?  Ant doesn't know where to get
> junit either.  Simply
> make the presence of antunit a requirement just as
> we require junit
> today.

So it could be fetched in some way similar to that
done by fetch.xml ...

-Matt

(sorry I forgot to respond yesterday)

> 
> Stefan
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 2 Nov 2005, Matt Benson <gu...@yahoo.com> wrote:

> How does Ant know where to get antunit?  From SVN? 

Does it need to?  Ant doesn't know where to get junit either.  Simply
make the presence of antunit a requirement just as we require junit
today.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: AntUnit

Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:

> On Wed, 2 Nov 2005, Matt Benson
> <gu...@yahoo.com> wrote:
> 
> > Again, I am anxious to get all of Ant's tests
> migrated
> > to Antunit,
> 
> I'm not sure whether "all" is the best goal, but a
> lot of them can be.
> Looking over the tests I've added over the past
> weeks, I really only
> needed antunit's capabilities.

Most of the unit tests are, IMO, this way.  I think
80% would be a conservative guess.
> 
> > but haven't been able to get my head around how to
> integrate them
> > organization-wise. Circular dependencies and all. 
> Would build.xml
> > build antunit, then use it?
> 
> After bootstrapping, yes.  There is no circular
> dependency since you
> don't need antunit to build Ant, only to test it.

How does Ant know where to get antunit?  From SVN? 
Using what? The svn antlib?  How does Ant know where
to get _that_? ;) I wonder if the maven2 tasks could
be helpful here...

-Matt

> 
> Stefan
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org