DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20791>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20791
[PATCH] add support to <junit> for popping up the JUnit GUI
------- Additional Comments From spud@madbean.com 2003-06-19 11:55 -------
I agree that it is totally overloading the <junit> task. I'll try and
outline my reasons for submitting the patch I have.
> I wonder what the 'uimode' gives you that cannot be easily done by just using
> <java classname="junit.swingui.Runner">? Is it the specification of the tests
to
> run via <test>/<batchtest>? The classpath configuration?
This is *exactly* what I was trying to achieve: re-use of the <test>
and <batchtest> clauses; plus their associated classpaths, 'if' and
'unless' behaviour, <exclude> and <include> statements (with *their*
own 'if' and 'unless' behaviour).
My patch is based upon these principles/assumptions:
1) it is common that projects use <junit> for automated testing
("continuous integration" scenarios).
2) it is common that projects use the same build files for continuous
integration AND for desktop development (ie; during the daily
code/build/test cycle)
3) when maintaining Ant build files, the DRY principle is useful: Don't
Repeat Yourself.
So, the current <junit> task certainly fulfills 1) above.
I think JUnit's own GUIs enhance the desktop-development experience. I
think there is an inherent *goodness* about seeing the
green-bar. And being able to run a project's unit tests *during
development* is crucial to avoiding software rot in the test code.
So, *some* ability to run "development friendly" tests is what is
required by 2) but, for me, the html or text formatters don't cut it,
nor does "print summary". I like to see the JUnit GUI; and I suppose
that I can achieve that with a <java classname="junit.swingui.Runner">
but...
The DRY principle suggests should we should only need to specify our
unit tests once; whether we are running the GUI, or not. And *that* is
the goal of my patch.
As an example, Ant's own build.xml file has a <junit> specification
that spans 127 lines. This specification lists MANY excluded tests
based upon library availability, sets system properties and sets
classpaths. It has just one line detailing a <formatter> :)
In addition, my uimode="true" patch allows you to do something with
<junit> that cannot be done with junit.swingui.Runner, which is to use
selectors and Ant file-sets to specify what all your tests are; in
JUnit you need to set up your suite() methods, etc.
So, that is my case for the patch. If it is deemed that a separate
<junitgui> task is preferable, then I will pursue that path. In that
case, I may put forward a proposal for a new ant type that captures
the information specified by <batchtest>/<test>, so that it can be
used by multiple <junit> and <junitgui> tasks. (I suppose this info is
just a <classpath> and a <fileset> which are types that can just be
used as-is.)
=Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
|