You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ingmar Stein <st...@xtramind.com> on 2001/09/11 15:22:43 UTC
JUnit writes properties for each testcase
Hi all,
we have a very large number of unit tests here that are run by a single
batchtest. The Junit task writes the system properties for each and every
testcase which is a rather huge waste of space as all test share the same
property set.
Could someone write a fix for that?
Ingmar
Re: JUnit writes properties for each testcase
Posted by Ingmar Stein <st...@xtramind.com>.
> > Could someone write a fix for that?
> You?
Man, I'm lazy as hell ;-)
Re: JUnit writes properties for each testcase
Posted by Maurice le Rutte <mp...@oce.nl>.
> Could someone write a fix for that?
You?
Re: [PATCH] JUnit writes properties for each testcase
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Peter,
Have a look at Ingmar's response to this thread:
http://www.mail-archive.com/ant-dev@jakarta.apache.org/msg09735.html
Because of the architecture of the JUnit/JUnitReport tasks and how they work
with fork="true" it won't work to separate when the properties are gathered
from when the tests are run (it works, just is not necessarily in sync with
one another).
So I'm pretty sure Ingmar gave up on this change. Ingmar?
Erik
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Monday, October 01, 2001 3:23 AM
Subject: Re: [PATCH] JUnit writes properties for each testcase
> Hi,
>
> has anyone looked at this patch? It is not somethign I use so I don't know
> how useful/good/whatever it is ;)
>
> On Thu, 13 Sep 2001 00:41, Ingmar Stein wrote:
> > With this tiny patch, junitreport will merge the properties file
generated
> > by the xmlproperties task with the testsuites. The resulting XML may
> > be processed with a new version of junit-frames.xsl (coming soon).
> >
> > Sorry about the diff not being unified, but the solaris diff doesn't
seem
> > to support them :-/
> >
> > ----- Original Message -----
> > From: "Ingmar Stein" <st...@xtramind.com>
> > To: <an...@jakarta.apache.org>
> > Sent: Wednesday, September 12, 2001 4:09 PM
> > Subject: Re: JUnit writes properties for each testcase
> >
> > > Okay, here's task that takes a property file and writes the stored
> > > properties into an XML file. If no property file is specified, it
> > > uses the Ant and the system properties.
>
> --
> Cheers,
>
> Pete
>
> "You know what a dumbshit the 'average man' on the street is? Well, by
> definition, half of them are even dumber than that!"
> J.R. "Bob" Dobbs
>
Re: [PATCH] JUnit writes properties for each testcase
Posted by Peter Donald <do...@apache.org>.
Hi,
has anyone looked at this patch? It is not somethign I use so I don't know
how useful/good/whatever it is ;)
On Thu, 13 Sep 2001 00:41, Ingmar Stein wrote:
> With this tiny patch, junitreport will merge the properties file generated
> by the xmlproperties task with the testsuites. The resulting XML may
> be processed with a new version of junit-frames.xsl (coming soon).
>
> Sorry about the diff not being unified, but the solaris diff doesn't seem
> to support them :-/
>
> ----- Original Message -----
> From: "Ingmar Stein" <st...@xtramind.com>
> To: <an...@jakarta.apache.org>
> Sent: Wednesday, September 12, 2001 4:09 PM
> Subject: Re: JUnit writes properties for each testcase
>
> > Okay, here's task that takes a property file and writes the stored
> > properties into an XML file. If no property file is specified, it
> > uses the Ant and the system properties.
--
Cheers,
Pete
"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
J.R. "Bob" Dobbs
Re: JUnit writes properties for each testcase
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
> Yep. Maybe we could use putAll there as well instead of enumerating all
> keys and adding the corresponding values.
Yes, I'll add that to my Ant "to do" list.
> The fact that system properties may differ if the junit task is forked
makes
> xmlproperties useless
> for my use case as there is no way for this task to know what the system
> properties will be... dammit
Sorry 'bout that. Perhaps we can all work together from Stephane's start
on refactoring the JUnit task such that its much tighter when dealing with
forked versus "in VM" execution and that its results gathering doesn't
generate duplicate information.
Erik
Re: JUnit writes properties for each testcase
Posted by Ingmar Stein <st...@xtramind.com>.
> Just for information purposes, it looks like you borrowed the method for
> getting properties from JUnitTestRunner, which is fine, but
Yep. Maybe we could use putAll there as well instead of enumerating all
keys and adding the corresponding values.
> > /* add ant system properties */
> > props.putAll( project.getProperties() );
> >
> > /* add/overlay system properties */
> > props.putAll( System.getProperties() );
>
> within a task, there is no need to overlay System properties on Ant
> properties as Ant's properties contain the System properties already.
The
> reason JUnitTestRunner does it is because that code is
JUnitTestRunner.main
> is used when forking <junit> and so the System properties could be
different
> than Ant's version of them.
Oops, I didn't notice that project.getProperties already contains the system
properties. Thanks.
The fact that system properties may differ if the junit task is forked makes
xmlproperties useless
for my use case as there is no way for this task to know what the system
properties will be... dammit
> Having a task handy that outputs the Ant properties in XML format is a
good
> thing. Thank you.
No problem...
Re: JUnit writes properties for each testcase
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Ingmar,
Just for information purposes, it looks like you borrowed the method for
getting properties from JUnitTestRunner, which is fine, but
> /* add ant system properties */
> props.putAll( project.getProperties() );
>
> /* add/overlay system properties */
> props.putAll( System.getProperties() );
within a task, there is no need to overlay System properties on Ant
properties as Ant's properties contain the System properties already. The
reason JUnitTestRunner does it is because that code is JUnitTestRunner.main
is used when forking <junit> and so the System properties could be different
than Ant's version of them.
Having a task handy that outputs the Ant properties in XML format is a good
thing. Thank you.
Erik
[PATCH] JUnit writes properties for each testcase
Posted by Ingmar Stein <st...@xtramind.com>.
With this tiny patch, junitreport will merge the properties file generated
by the xmlproperties task with the testsuites. The resulting XML may
be processed with a new version of junit-frames.xsl (coming soon).
Sorry about the diff not being unified, but the solaris diff doesn't seem
to support them :-/
----- Original Message -----
From: "Ingmar Stein" <st...@xtramind.com>
To: <an...@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 4:09 PM
Subject: Re: JUnit writes properties for each testcase
> Okay, here's task that takes a property file and writes the stored
> properties into an XML file. If no property file is specified, it
> uses the Ant and the system properties.
Re: JUnit writes properties for each testcase
Posted by Ingmar Stein <st...@xtramind.com>.
Okay, here's task that takes a property file and writes the stored
properties into an XML file. If no property file is specified, it
uses the Ant and the system properties.
import java.io.*;
import java.util.Properties;
import java.util.Enumeration;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.util.DOMElementWriter;
/**
* Creates an XML file with all Ant and system properties.
* @author Ingmar Stein (stein@xtramind.com)
* @version $Id: XMLProperties.java,v 1.1 2001/09/12 14:03:06 stein Exp $
*/
public class XMLProperties extends Task
{
private File outFile = null;
private File inFile = null;
/** the properties element */
private final static String PROPERTIES = "properties";
/** the property element */
private final static String PROPERTY = "property";
/** name attribute for property, testcase and testsuite elements */
private final static String ATTR_NAME = "name";
/** value attribute for property elements */
private final static String ATTR_VALUE = "value";
private static DocumentBuilder getDocumentBuilder()
{
try {
return DocumentBuilderFactory.newInstance().newDocumentBuilder();
} catch(Exception e) {
throw new ExceptionInInitializerError(e);
}
}
public void setOut( File file )
{
outFile = file;
}
public void setIn( File file )
{
inFile = file;
}
/**
* Runs the task.
* @throws BuildException if someting goes wrong
*/
public void execute() throws BuildException
{
Properties props = new Properties();
if( outFile == null ) {
throw new BuildException( "the out attribute must be set." );
}
if( inFile == null ) {
/* add ant system properties */
props.putAll( project.getProperties() );
/* add/overlay system properties */
props.putAll( System.getProperties() );
} else {
try {
FileInputStream in = new FileInputStream( inFile );
props.load( in );
in.close();
} catch( FileNotFoundException fnfe ) {
log( "Could not find file " + inFile.getAbsolutePath(),
Project.MSG_WARN );
return;
} catch( IOException ioe ) {
log( "Could not read file " + inFile.getAbsolutePath(),
Project.MSG_WARN );
return;
}
}
// create XML document
Document doc = getDocumentBuilder().newDocument();
Element rootElement = doc.createElement( PROPERTIES );
// output properties
String name;
Enumeration e = props.propertyNames();
while( e.hasMoreElements() ) {
name = (String)e.nextElement();
Element propElement = doc.createElement( PROPERTY );
propElement.setAttribute( ATTR_NAME, name );
propElement.setAttribute( ATTR_VALUE, props.getProperty(name) );
rootElement.appendChild( propElement );
}
Writer wri = null;
try {
OutputStream out = new FileOutputStream( outFile );
wri = new OutputStreamWriter( out, "UTF8" );
wri.write( "<?xml version=\"1.0\"?>\n" );
(new DOMElementWriter()).write( rootElement, wri, 0, "\t" );
wri.flush();
} catch( IOException ioe ) {
throw new BuildException( "Unable to write XML file", ioe );
} finally {
if( wri != null ) {
try {
wri.close();
} catch (IOException ioe) {}
}
}
}
}
----- Original Message -----
From: "Erik Hatcher" <ja...@ehatchersolutions.com>
To: <an...@jakarta.apache.org>
Sent: Wednesday, September 12, 2001 7:49 AM
Subject: Re: JUnit writes properties for each testcase
> Here's another possibility as a workaround:
>
> - Write out your relevant properties using <propertyfile> (I'd be willing
to
> contribute a patch that would provide a single element or switch that
would
> automatically dump all of Ant's properties with that task - seems like
that
> could be a handy capability to have available anyway).
> - Customize the XSL that <junitreport> uses and add a hyperlink to the
text
> file containing the properties so you could easily access it when viewing
> the reports.
>
> Another idea:
>
> - Implement a task that creates an XML file with all the properties listed
> - Use the <style> task to convert that to an HTML file
> - Hyperlink in the HTML file to a customized version of the <junitreport>
> XSL.
>
> Both of these are of course hacks but might suffice for your needs.
>
> Is there a way to have an XSL transformation read in two XML files?
> Perhaps merging in the properties wouldn't be that difficult if a custom
> task could generate the properties in XML format.
>
> All of these ideas also, of course, rely on a modification to the <junit>
> task to be able to turn off the properties output if desired. Other than
> these workarounds I think it will involve serious refactoring of how the
> JUnit task works in order to accomplish what you are asking for.
>
> Erik
Re: JUnit writes properties for each testcase
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Here's another possibility as a workaround:
- Write out your relevant properties using <propertyfile> (I'd be willing to
contribute a patch that would provide a single element or switch that would
automatically dump all of Ant's properties with that task - seems like that
could be a handy capability to have available anyway).
- Customize the XSL that <junitreport> uses and add a hyperlink to the text
file containing the properties so you could easily access it when viewing
the reports.
Another idea:
- Implement a task that creates an XML file with all the properties listed
- Use the <style> task to convert that to an HTML file
- Hyperlink in the HTML file to a customized version of the <junitreport>
XSL.
Both of these are of course hacks but might suffice for your needs.
Is there a way to have an XSL transformation read in two XML files?
Perhaps merging in the properties wouldn't be that difficult if a custom
task could generate the properties in XML format.
All of these ideas also, of course, rely on a modification to the <junit>
task to be able to turn off the properties output if desired. Other than
these workarounds I think it will involve serious refactoring of how the
JUnit task works in order to accomplish what you are asking for.
Erik
----- Original Message -----
From: "Ingmar Stein" <st...@xtramind.com>
To: <an...@jakarta.apache.org>
Sent: Tuesday, September 11, 2001 6:48 AM
Subject: Re: JUnit writes properties for each testcase
> > How do you propose a solution? Would an option to turn off property
> > gathering altogether be acceptable? It would not really make sense to
> only
> > gather the properties once, so I'd think an on/off switch would be the
> best
> > way to handle it.
>
> No, I need the properties...
> A singe file that is merged with the junitreport task would suffice...
>
> Ingmar
>
>
Re: JUnit writes properties for each testcase
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Thats a fairly involved modification, as the merge is independent of the
actual tests and results gathering. Care would have to be taken (and I'm
not sure how this would be done) to ensure that the properties were matched
to the tests appropriately.
I know Stephane has some thoughts on refactoring how the JUnit tasks work,
so perhaps its time for us to start down that path and figure out a better
way for it to work.
Erik
----- Original Message -----
From: "Ingmar Stein" <st...@xtramind.com>
To: <an...@jakarta.apache.org>
Sent: Tuesday, September 11, 2001 6:48 AM
Subject: Re: JUnit writes properties for each testcase
> > How do you propose a solution? Would an option to turn off property
> > gathering altogether be acceptable? It would not really make sense to
> only
> > gather the properties once, so I'd think an on/off switch would be the
> best
> > way to handle it.
>
> No, I need the properties...
> A singe file that is merged with the junitreport task would suffice...
>
> Ingmar
>
>
Re: JUnit writes properties for each testcase
Posted by Ingmar Stein <st...@xtramind.com>.
> How do you propose a solution? Would an option to turn off property
> gathering altogether be acceptable? It would not really make sense to
only
> gather the properties once, so I'd think an on/off switch would be the
best
> way to handle it.
No, I need the properties...
A singe file that is merged with the junitreport task would suffice...
Ingmar
Re: JUnit writes properties for each testcase
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
How do you propose a solution? Would an option to turn off property
gathering altogether be acceptable? It would not really make sense to only
gather the properties once, so I'd think an on/off switch would be the best
way to handle it.
Erik
----- Original Message -----
From: "Ingmar Stein" <st...@xtramind.com>
To: <an...@jakarta.apache.org>
Sent: Tuesday, September 11, 2001 6:22 AM
Subject: JUnit writes properties for each testcase
> Hi all,
>
> we have a very large number of unit tests here that are run by a single
> batchtest. The Junit task writes the system properties for each and every
> testcase which is a rather huge waste of space as all test share the same
> property set.
> Could someone write a fix for that?
>
> Ingmar
>
>