ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: <junit> and junit4 (long)
Date Thu, 25 May 2006 20:49:43 GMT
Stefan Bodewig wrote:
> On Thu, 25 May 2006, Steve Loughran <stevel@apache.org> wrote:
> 
> 
>>I guess junit4 is extra motivation for us to stick a beta of that
>>out soon.
> 
> 
> All we need is a release plan to vote on as well as a release manager ;-)
> 
> 
>>We discussed where this task would go (antlib under ant vs. antlib
>>at junit.org), and what the stability/redist implications would
>>be. junit uses java which is very backwards compatible, though
>>ant1.7 improves some things. Putting it in with junit4 gives it a
>>tighter coupling to junit.
>>
>>I think the consensus was that the junit CVS repository (on
>>sourceforge) is the place to do this,
> 
> 
> I agree, if only sf's CVS was reliable.

It's been functional for 30+ hours now. When last it went down (monday) 
they did put a note in their status log, albeit on tuesday.

my concern is not the availability of CVS, but the quality of the 
filesystem. I hope when they rebuilt the disks they moved on from ext2 
filesys.

> 
> 
>>1. Who wants to help work on a new junit task?
> 
> 
> count me in.
> 
> 
>>(2) what should it do?
>>
>>   -Everything in <junit>,
> 
> 
> At least most of it.

what would you drop?


For reference, these are the presets I use for testing. I always give a 
default timeout, even if it is hours long, because automated build tools 
dont notice hangs and can run for days without giving up


     <presetdef name="junit" uri="${core.uri}">
       <junit printsummary="no"
            fork="true"
            includeantruntime="true"
            showoutput="true"
            >
        <jvmarg value="-ea"/>
        <jvmarg value="-esa"/>
         <!-- #Tests take system property parameters -->
         <!-- #Formatters for capture and display -->
         <formatter type="xml"/>
         <formatter type="brief" usefile="false"/>
       </junit>
     </presetdef>

     <!-- reporting wrapper -->
     <macrodef name="test-report" uri="${core.uri}">
       <attribute name="data"/>
       <attribute name="reports"/>
       <attribute name="failed" 
default="a.property.that.had.better.never.be.set"/>
       <sequential>
         <junitreport todir="@{data}">
           <fileset dir="@{data}">
             <include name="TEST-*.xml"/>
           </fileset>
           <report format="frames" todir="@{reports}"/>
         </junitreport>
         <fail if="@{failed}">Unit tests failed see @{reports}</fail>
       </sequential>
     </macrodef>

> 
> 
>>3. enhancements to junit
>>
>>    -a method "isFailure" on the assertion failure classes, for
>>    checking (through reflection in ant) for failures vs errors.
> 
> 
> Yes, that would be handy.  But they shouldn't have dropped the
> difference between errors and failures in the first place.

well, you can add that to the wish list.


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


Mime
View raw message