ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 20791] - [PATCH] add support to <junit> for popping up the JUnit GUI
Date Thu, 19 Jun 2003 11:55:33 GMT
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


Mime
View raw message