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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
