Hello,
I'm working on a build system based on plugin, and I'm currently writting a
'junit' plugin to call test cases and to generate report...
And I find the 'junit' optionnal task really complex (from the user-side point
of view). The big trouble for me is that it is possible to declare parameters
that will not work properly: ignored arguments with fork options or mode,
overwritten arguments in test declaration, many formatter possibilities...
And the only obvious aim of that complexity is to avoid to call the 'junit'
task many times with adequat options.
As a proposal, I think a simpler 'junit' task would be enough and may avoid
troubles:
. Java argument options (classpath, forkmode, environment, system properties)
. Formatter options
. filesets to filter TestCases to run (or a single file name)
When reading a 'junit' invocation, there will be no doubt how it will behave:
one JVM for all tests or one per test, same JVM options and same formatters
for all declared test cases.
In that case, JUnitTask may inherit from Java task and code will be really
simpler I think.
As an example, I have found a strange behavior of the internal
JUnitTestRunner. Here is the corresponding command line:
<java
fork="yes"
dir="${module.runtime.directory}"
classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner">
<classpath
path="${module.classpath}:apache-ant-1.6.2/lib/ant-junit.jar:apache-ant-1.6.2/lib/ant.jar"/>
<arg value="testsfile=${module.testcases}"/>
<arg value="haltOnError=off"/>
<arg value="haltOnFailure=off"/>
<!-- Show Summary on console -->
<arg
value="formatter=org.apache.tools.ant.taskdefs.optional.junit.SummaryJUnitResultFormatter"/>
<!-- Generate XML report for this test suite -->
<arg
value="formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,${module.report}"/>
</java>
If ${module.report} parameter is removed after XMLJUnitResultFormatter, the
XML report is outputed in the console - whereas the ${module.testcases} file
declares an output directory and file per TestCase !
If the parameter ${module.report} is present, output files declared in
${module.testcases} file are correctly generated BUT their is no generated
file with name ${module.report} !!
Strange isn't it ? In fact, the JUnitTestRunner command line is also a clue of
the complexity of the 'junit' task.
As a conclusion I consider the 'junit' may be replace by a simpler
implementation that may avoid confusion about how it behaves. The only
difference is that you need to call many 'junit' when parameters differ from a
test case set to another... But I find it a good think !
What is your opinion ? Is it worth to create a simpler 'junit' task ?
Regards,
--
Yves Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
