You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@apache.org> on 2006/05/25 14:36:55 UTC
and junit4 (long)
Jesse Glick and I had a phone conf with a couple of JUnit people,
including Kent Beck, on the future of <junit>
They've been getting reports of junit4/<junit> problems, which is not
surprising given that ant1.65. doesn't work with junit4. We discussed
what is coming in Ant1.7, and I guess junit4 is extra motivation for us
to stick a beta of that out soon.
We discussed the recurrent support calls related to <junit> that we see
-junit.jar not on ant's classpath
-setting up the xml listener (needs xml parser on the path)
-xml reports don’t fully escape everything they should, and when the app
terminates there is an empty xml file (because it buffers everything
in a test case)
-<junit> tries to run abstract test cases (no check for the abstract bit)
-people don't get their selection patterns right, and we try and run
things that arent tests. We could do a check here for 3.x, but not for
junit 4.
-People get extra burned when their pattern is **/Test* and they have
a nested inner class, because of course that TestSomething$Inner.class
matches the pattern
-not well integrated with logging APIs. we get the text as printed to
stdout, but lose the full log metadata. If we had something behind
commons-logging we could capture logs as data rather than as stdout
messages.
-most of the methods are public, we know the task is delegated to, and
probably
subclassed, so are constrained in what we can change.
Jesse also explained what is done for junit4 support
-exception class name pattern matching to distinguish faults from errors
-suite() support
-reflection for all this stuff so it builds on java1.4
-picking up of junit4 before junit3
The consensus was that a new junit4 antlib/task would be the way
forward, one that had the same attributes/elements as <junit>, better
defaults (assertions on, fork=true?), and designed to run junit4 (and so
compile on java5 only).
It could then add new stuff for junit4, like recognise ignored tests and
still report them. We'd need a new task/stylesheet for reporting junit4
runs.
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, but that ant developers need to provide help,
ant users can provide input on wants/needs.
1. Who wants to help work on a new junit task?
2. What should it do?
3. Are there any enhancements we'd like to see in junit4 classes to help
us?
My responses
(1) I would, with that caveat about no free time. I could send them the
chapters
of JdWA that cover writing ant tasks, when I finish them in the
next two
weeks (according to the schedule!)
(2) what should it do?
-Everything in <junit>,
-Offer control of any new options
-Listener interface enhancements
-allow for log events as well as stdout.
-provide our own commons logging/java logging back ends that route to
the listeners
-set the forked jvm up with the right properties to route to these
back ends
-XML listener to be enhanced with
-streaming of the output to file
-stick the results at the end of each run, instead of attributes on
the root
node (this is implicit with streaming)
-have some way of remembering which tests failed and only running
them. This
could be done with a listener that generates a file containing a
list of
classes that could be read by the task next time round and used to
select
classes to test
-skip abstract tests always
-skip inner classes (with a $ in the shortname) unless
testInnerClasses=true
(we could patch this back onto junit too)
3. enhancements to junit
-a method "isFailure" on the assertion failure classes, for checking
(through reflection in ant) for failures vs errors.
-I'd like serializable forms of test results, fault data and
statistics. I had to do my own for smartfrog junit components, code I
now share with gridunit. Serialized classes make it easy to share
results around or save
them to a file.
There isnt a formal junit mail list for developing this task; I think
there ought to be and then interested people can get on it. They are
going to put their dev branch onto gump though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by Steve Loughran <st...@apache.org>.
J. David Beutel wrote:
> Steve Loughran <st...@apache.org> wrote on 05/25/2006 02:36:55 AM:
>> The consensus was that a new junit4 antlib/task would be the way forward
> [...]
>> I think the consensus was that the junit CVS repository (on
>> sourceforge) is the place to do this, but that ant developers need to
>> provide help, ant users can provide input on wants/needs.
>
> I can't find it on that repository. Was it started somewhere else, or
> not yet?
>
nothing has been started yet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by "J. David Beutel" <jd...@getsu.com>.
Steve Loughran <st...@apache.org> wrote on 05/25/2006 02:36:55 AM:
> The consensus was that a new junit4 antlib/task would be the way forward
[...]
> I think the consensus was that the junit CVS repository (on
> sourceforge) is the place to do this, but that ant developers need to
> provide help, ant users can provide input on wants/needs.
I can't find it on that repository. Was it started somewhere else, or
not yet?
Cheers,
11011011
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Structure of Ant (OO Design)
Posted by Hayden Melton <hm...@ec.auckland.ac.nz>.
> So you analyse each of the source files to determine which other
> source files they depend on. This seems to be a Java-centric
> analysis in that it relies on the source files containing a class
> each? Is that correct? Ie would this be able to analyse source
> files that contain many classes (like in other languages which don't
> have the general 1 class/source file structure of Java)?
Yeah my analysis is Java-centric. In other languages there might be multiple
(top-level classes) per source file. Other people have suggested similar
analyses for other languages (see John Lakos, Large Scale C++ Software Design
http://www.amazon.com/gp/product/0201633620/002-6391393-4360864?v=glance&n=283155
)
In fact, Java can have multiple classes declared in one source file (nested
classes and inner classes. But since a source file is the usual `physical' unit
we deal with as programmers it makes sense to look at dependencies between
.java files.
> From you analysis, does the 'flatter' the structure have any
> correlation with the complexity of the code, or any other 'quality'
> metric?
Yip --- the flatter (and more `acyclic') the graph, the easier the system should
be to understand, test and reuse. I have explained the reasons why on my
research page:
http://www.cs.auckland.ac.nz/~hayden/research.htm
> Sorry to bug you about this, but I'm fairly interested in this (from
> a layman's perspective), and I've got a fairly easy day at work so
> I'm free to send inquiring emails :)
The raw data is available for Ant, along with the tool I used to collect the
data. My tool says that these classes are all (transitively) mutually dependent
in ant 1.6.5:
org.apache.tools.ant.filters.TokenFilter
org.apache.tools.ant.types.RegularExpression
org.apache.tools.ant.util.regexp.Regexp
org.apache.tools.ant.filters.BaseFilterReader
org.apache.tools.ant.types.selectors.ContainsRegexpSelector
org.apache.tools.ant.loader.AntClassLoader2
org.apache.tools.ant.types.selectors.DateSelector
org.apache.tools.ant.types.selectors.BaseSelectorContainer
org.apache.tools.ant.filters.PrefixLines
org.apache.tools.ant.AntClassLoader
org.apache.tools.ant.types.Reference
org.apache.tools.ant.filters.EscapeUnicode
org.apache.tools.ant.types.AntFilterReader
org.apache.tools.ant.types.selectors.NotSelector
org.apache.tools.ant.filters.HeadFilter
org.apache.tools.ant.taskdefs.condition.Condition
org.apache.tools.ant.ProjectHelper
org.apache.tools.ant.filters.ExpandProperties
org.apache.tools.ant.AntTypeDefinition
org.apache.tools.ant.filters.util.ChainReaderHelper
org.apache.tools.ant.types.AbstractFileSet
org.apache.tools.ant.types.EnumeratedAttribute
org.apache.tools.ant.types.selectors.modifiedselector.DigestAlgorithm
org.apache.tools.ant.helper.ProjectHelper2
org.apache.tools.ant.util.JavaEnvUtils
org.apache.tools.ant.PropertyHelper
org.apache.tools.ant.types.Path
org.apache.tools.ant.taskdefs.Definer
org.apache.tools.ant.types.selectors.ExtendSelector
org.apache.tools.ant.DynamicAttributeNS
org.apache.tools.ant.DynamicAttribute
org.apache.tools.ant.UnsupportedElementException
org.apache.tools.ant.BuildEvent
org.apache.tools.ant.types.selectors.BaseSelector
org.apache.tools.ant.types.FilterSetCollection
org.apache.tools.ant.types.FilterChain
org.apache.tools.ant.RuntimeConfigurable
org.apache.tools.ant.TypeAdapter
org.apache.tools.ant.types.selectors.DepthSelector
org.apache.tools.ant.util.JAXPUtils
org.apache.tools.ant.util.LineTokenizer
org.apache.tools.ant.input.DefaultInputHandler
org.apache.tools.ant.DirectoryScanner
org.apache.tools.ant.types.FileList
org.apache.tools.ant.types.selectors.MajoritySelector
org.apache.tools.ant.taskdefs.Manifest
org.apache.tools.ant.Executor
org.apache.tools.ant.taskdefs.DefBase
org.apache.tools.ant.types.selectors.SizeSelector
org.apache.tools.ant.util.FileUtils
org.apache.tools.ant.types.selectors.modifiedselector.ModifiedSelector
org.apache.tools.ant.types.selectors.MappingSelector
org.apache.tools.ant.SubBuildListener
org.apache.tools.ant.types.DataType
org.apache.tools.ant.types.Substitution
org.apache.tools.ant.Project
org.apache.tools.ant.types.selectors.DifferentSelector
org.apache.tools.ant.types.selectors.PresentSelector
org.apache.tools.ant.filters.TailFilter
org.apache.tools.ant.helper.AntXMLContext
org.apache.tools.ant.input.InputHandler
org.apache.tools.ant.helper.ProjectHelperImpl
org.apache.tools.ant.filters.ClassConstants
org.apache.tools.ant.taskdefs.Antlib
org.apache.tools.ant.util.LoaderUtils
org.apache.tools.ant.types.Mapper
org.apache.tools.ant.PathTokenizer
org.apache.tools.ant.types.selectors.SelectorContainer
org.apache.tools.ant.taskdefs.AntlibDefinition
org.apache.tools.ant.filters.StripLineBreaks
org.apache.tools.ant.filters.StripLineComments
org.apache.tools.ant.types.FilterSet
org.apache.tools.ant.util.regexp.RegexpMatcherFactory
org.apache.tools.ant.ComponentHelper
org.apache.tools.ant.types.selectors.SelectSelector
org.apache.tools.ant.ProjectComponent
org.apache.tools.ant.types.PatternSet
org.apache.tools.ant.types.selectors.FilenameSelector
org.apache.tools.ant.types.Description
org.apache.tools.ant.types.selectors.SelectorScanner
org.apache.tools.ant.util.CompositeMapper
org.apache.tools.ant.util.ContainerMapper
org.apache.tools.ant.taskdefs.Typedef
org.apache.tools.ant.taskdefs.condition.Os
org.apache.tools.ant.types.selectors.TypeSelector
org.apache.tools.ant.types.selectors.FileSelector
org.apache.tools.ant.TaskContainer
org.apache.tools.ant.types.selectors.AndSelector
org.apache.tools.ant.types.selectors.BaseExtendSelector
org.apache.tools.ant.TaskAdapter
org.apache.tools.ant.filters.StripJavaComments
org.apache.tools.ant.filters.TabsToSpaces
org.apache.tools.ant.types.selectors.DependSelector
org.apache.tools.ant.util.regexp.RegexpFactory
org.apache.tools.ant.UnsupportedAttributeException
org.apache.tools.ant.filters.LineContainsRegExp
org.apache.tools.ant.DynamicElement
org.apache.tools.ant.BuildListener
org.apache.tools.ant.taskdefs.PreSetDef
org.apache.tools.ant.filters.ReplaceTokens
org.apache.tools.ant.Task
org.apache.tools.ant.types.selectors.ExtendFileSelector
org.apache.tools.ant.types.selectors.NoneSelector
org.apache.tools.ant.UnknownElement
org.apache.tools.ant.types.selectors.ContainsSelector
org.apache.tools.ant.types.FileSet
org.apache.tools.ant.Location
org.apache.tools.ant.util.regexp.RegexpMatcher
org.apache.tools.ant.DynamicElementNS
org.apache.tools.ant.BuildException
org.apache.tools.ant.Target
org.apache.tools.ant.types.DirSet
org.apache.tools.ant.IntrospectionHelper
org.apache.tools.ant.types.selectors.OrSelector
org.apache.tools.ant.filters.BaseParamFilterReader
org.apache.tools.ant.filters.LineContains
org.apache.tools.ant.util.ClasspathUtils
> On the other hand I suppose I should really read your research
> properly as you've probably described exactly how and where your
> analysis works/fails
Yeah, you should take a gander. Pretty much everything I have said in this email
is explained there. It might be a bit wordy, but I have tried to be thorough.
Incidentally, I have posted to a number of mailing lists results that I have
collected from analysing various applications. All the feedback I get from
developers about their feelings on the quality of the design of their system
w.r.t. transitive compilation dependencies is very useful for my research.
Cheers,
/
Hayden.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Structure of Ant (OO Design)
Posted by Kev Jackson <fo...@gmail.com>.
On 5 Jun 2006, at 10:07, Hayden Melton wrote:
> Ant-1.6.5 there are 117 .java files involved in a big dependency
> cycle.
> That is the height of the biggest red bar. The yellow bars show the
> distribution of another metric I have devised CRSS which aims to
> quantify how
> "flat" the structure of a system is.
So you analyse each of the source files to determine which other
source files they depend on. This seems to be a Java-centric
analysis in that it relies on the source files containing a class
each? Is that correct? Ie would this be able to analyse source
files that contain many classes (like in other languages which don't
have the general 1 class/source file structure of Java)?
From you analysis, does the 'flatter' the structure have any
correlation with the complexity of the code, or any other 'quality'
metric?
Sorry to bug you about this, but I'm fairly interested in this (from
a layman's perspective), and I've got a fairly easy day at work so
I'm free to send inquiring emails :)
On the other hand I suppose I should really read your research
properly as you've probably described exactly how and where your
analysis works/fails
Kev
--
"Society in every state is a blessing, but government even in its
best state is but a necessary evil; in it's worst state an
intolerable one" - Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Structure of Ant (OO Design)
Posted by Hayden Melton <hm...@ec.auckland.ac.nz>.
> Is your analysis in any way similar to how PMD defines it's cyclic
> complexity metric? I always thought that PMD did a good job of
> warning developers of potentially 'smelly' code.
No, it has nothing to do with McCabe's cyclomatic complexity, which basically
tries to quantify the complexity of the control flow in a method (i.e. how many
different paths there are through if-statemetns, loops etc).
Basically what I'm doing is lookin at compilation dependencies among source
files. So if A.java depends on B.java, and B.java depends on C.java, and C.java
depends on A.java, then A.java and B.java and C.java are all in a dependency
cycle.
Graphically:
- -> A -> B -> C --
` |
\_ _ _ _ _ _ _ _ _/
So in Ant-1.6.5 there are 117 .java files involved in a big dependency cycle.
That is the height of the biggest red bar. The yellow bars show the
distribution of another metric I have devised CRSS which aims to quantify how
"flat" the structure of a system is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Structure of Ant (OO Design)
Posted by Kev Jackson <fo...@gmail.com>.
On 3 Jun 2006, at 13:16, Hayden Melton wrote:
> http://www.cs.auckland.ac.nz/~hayden/corpus.htm
<quote>
If you're too busy to read my research page, and want to use these
graphs to tell a "good" from "bad" structure: big red bars are bad.
</quote>
Love that! Still not sure how to interpret the graphs, but at least
from that description, the less red on the graph the better :)
Is your analysis in any way similar to how PMD defines it's cyclic
complexity metric? I always thought that PMD did a good job of
warning developers of potentially 'smelly' code.
How do you generate the data to build the graphs? Do you have an ant
task to analyse the ant code?! :)
Good stuff to see anyway, shame I'm not smart enough (nor
conscientious enough to read your research page thoroughly) to
understand all of it apart from the overview you so eloquently
provided (quoted above)
Thanks for this
Kev
--
"I call it the State where everyone, good or bad, is a poison-
drinker: the State where universal slow suicide is called - life" -
Friedrich Nietzsche
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Structure of Ant (OO Design)
Posted by Hayden Melton <hm...@ec.auckland.ac.nz>.
Hi all,
I am a PhD student at the University of Auckland, New Zealand. As part of my
research I have performed an empirical study on a large corpus of open-source
Java software. Several of the applications in the corpus (Ant, Tomcat, JMeter,
POI) are from the Apache Software Foundation. If you are a developer of Ant you
might be interested to know that there are 117 source files all involved in a
big dependency cycle (Strongly connected component). Other applications like
Azureus, Soot and ArgoUML have strongly connected components involving ~1000
classes. In any case, a comparison of Ant to all the other applications in the
corpus is available on my webpage:
http://www.cs.auckland.ac.nz/~hayden/corpus.htm
The page also contains a graph that shows the evolution of dependencies through
around 10 versions of Ant, starting at Ant-1.1.
/
Hayden Melton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
>> 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.
Whatever you think of the decision to drop that distinction (personally
I am on the fence about it), the job of the task is to provide a wrapper
for the tool the way it is intended to be used, so for junit4 that means
report output should not differentiate between the two.
I *did* include differentiation in the patch I did in Ant head. But that
is only because the existing junit3-based reporting framework counts
failures and errors separately, and it would be confusing for one or the
other column to always be zero.
-J.
--
jesse.glick@sun.com x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Re: and junit4 (long)
Posted by Antoine Levy-Lambert <an...@gmx.de>.
> -------- Original-Nachricht --------
> Datum: Thu, 25 May 2006 16:08:37 +0200
> Von: Stefan Bodewig <bo...@apache.org>
> An: dev@ant.apache.org
> Betreff: Re: <junit> and junit4 (long)
>
> On Thu, 25 May 2006, Steve Loughran <st...@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 ;-)
I would be glad if someone else wants to be release manager for 1.7
Maybe if nobody else volunteers, I will do it again.
>
> Stefan
>
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
>> what would you drop?
>
> The attributes that are shortcuts for formatters, printsummary and
> showoutput.
For what it's worth, *every time* I write a <junit> usage by hand
(rather than copying from a prior example), I forget to specify
<formatter type="plain" usefile="false"/>
and am confused when the task quietly exits with no summary. Not sure if
anyone else has this problem. I agree that redundant attrs should be
removed. Perhaps there should be no formatters by default, but if you
forget to specify any at all, you get a descriptive error message with a
hint on how to add at least console (logged) output. (Add a "silent"
formatter for the special case that you really want no output and just
care about pass/fail.)
And I would make usefile="false" the default for formatters, or rather
have an optional file param, just like other tasks do.
> And I'd remove tempdir and always use ${java.io.tempdir}.
Might be a problem for scripts run on multiuser machines. I would use
${java.io.tmpdir} as a default but permit it to be overridden, perhaps.
IMHO no task should ever use ${basedir} as a default temp dir. People
should not have to dump all kinds of weird entries into their .cvsignore
files on Ant's account. If you need a non-default temp dir you can use
e.g. ${basedir}/build or wherever you normally put generated files.
-J.
--
jesse.glick@sun.com x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 25 May 2006, Steve Loughran <st...@apache.org> wrote:
> Stefan Bodewig wrote:
>> On Thu, 25 May 2006, Steve Loughran <st...@apache.org> wrote:
>>>(2) what should it do?
>>>
>>> -Everything in <junit>,
>> At least most of it.
>
> what would you drop?
The attributes that are shortcuts for formatters, printsummary and
showoutput. And I'd remove tempdir and always use ${java.io.tempdir}.
> 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
I thought about dropping timeout since JUnit has @Timeout, but you
have a point here.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Thu, 25 May 2006, Steve Loughran <st...@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
Re: and junit4 (long)
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 25 May 2006, Steve Loughran <st...@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.
> 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.
> 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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
junitreport [was and junit4 (long)]
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Steve, Stefan, and all Ants ...,
> -------- Original-Nachricht --------
> Datum: Thu, 25 May 2006 13:36:55 +0100
> Von: Steve Loughran <st...@apache.org>
> An: Ant Developers List <de...@ant.apache.org>
> Betreff: <junit> and junit4 (long)
>
> -xml reports don’t fully escape everything they should, and when the
> app
> terminates there is an empty xml file (because it buffers everything
> in a test case)
>
Ivan Ivanov is preparing a new patch, this time for JUnitReport.
The idea will be to use XSLTProcess instead of the XalanExecutors to do the XML transformation.
So the previous change to XSLTProcess is actually going to enable us to delegate to XSLTProcess from JUnitReport, using the stylesheets which are present as zip entries in ant-junit.jar such as org\apache\tools\ant\taskdefs\optional\junit\xsl\junit-frames.xsl.
This is somehow related. However the xml file which Steve mentions is generated by <junit/>, not by <junitreport/>.
Regards,
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: and junit4 (long)
Posted by Jesse Glick <je...@sun.com>.
Steve Loughran wrote:
> -setting up the xml listener (needs xml parser on the path)
Are enough people still using JDK 1.2/3 that this remains a common
problem? Certainly irrelevant for a junit4 task which can assume JAXP.
> -people don't get their selection patterns right, and we try and run
> things that arent tests. We could do a check here for 3.x, but not for
> junit 4.
Might be possible even in junit4 - just check for classes with no @Test
annotations, perhaps.
> -People get extra burned when their pattern is **/Test* and they have a
> nested inner class, because of course that TestSomething$Inner.class
> matches the pattern
Rather than adding an ad-hoc attribute for this problem, I would suggest
just making sure we don't run non-tests. That would automatically take
care of this problem. (Unless your nested class is really a static
TestCase, in which case maybe you really wanted to run it!) And/or print
a warning if any *$*.class matches the pattern, telling people to use
includes="**/*Test.class"
if that is what they meant.
> -not well integrated with logging APIs. we get the text as printed to
> stdout, but lose the full log metadata. If we had something behind
> commons-logging we could capture logs as data rather than as stdout
> messages.
Is this really something that should be dealt with by an Ant task? Seems
to me that the proper home for this is a non-Ant-specific library to be
used by tests that need logging capture. You can capture to a file or to
a memory buffer which is included in a failure message if there is one.
> (1) I would [like to help], with that caveat about no free time.
I might be able to as well.
-J.
--
jesse.glick@sun.com x22801 netbeans.org ant.apache.org
http://google.com/search?q=e%5E%28pi*i%29%2B1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org