You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/08/21 12:39:03 UTC
Excalibur Junit
Hi,
Could someone who knows junit do the following. For some reason the tests run
ungodly slow. I suspect it is because it is forking the JVm and then doing
lots of work with XML and then XSL a bit later. While this is nice if you
want to generate reports etc it is no good for normal development. So there
has to be someway where none of this stuff reports/results etl al is
generated and everything is done in JVM. So if so could someone do it.
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Peter Donald <do...@apache.org>:
> Hi,
>
> Could someone who knows junit do the following. For some reason the
> tests run
> ungodly slow. I suspect it is because it is forking the JVm and then
> doing
> lots of work with XML and then XSL a bit later. While this is nice if
> you
> want to generate reports etc it is no good for normal development. So
> there
> has to be someway where none of this stuff reports/results etl al is
> generated and everything is done in JVM. So if so could someone do it.
There are several options. First you can comment out the formatter element in
the junit task. This will reduce test time (on my machine) from 41 secs. to 23
secs. on the excalibur repository. Next you can change the fork="true" attribute
to false on the junit element. But then the log messages don't gets onto the
console but you still see which tests failed. This reduces the to to 9 secs.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Berin Loritsch <bl...@apache.org>.
Jeff Turner wrote:
>
> I don't know what's going on here.. last week, I was experiencing just what
> you're talking about. Tests took >2 mins on an 800mhz Duron. Changing
> fork="true" to fork="false" made no difference.
Some of this may be due to virtual memory swapping. JVMs can be pretty heavy
handed.
>
> Now, after having done a clean checkout, unsetting ANT_HOME, and running
> './build.sh test', it takes 27 secs. The XSLT bit takes under 2 secs.
This is because you probably have Xalan 1.xx in your installed ANT_HOME,
but unessting ANT_HOME uses Xalan 2.xx in Avalon.
Or it could be the XML parser you are using....
> Btw, the following tests currently fail:
>
> testSubstituteErrorFile "file:src/test/test.xml" not found.
This is known--but since it is in Scratchpad, it is not as high a
priority.
> testActiveMonitorFailure "File not changed"
This is due in part to the fact that you machine is probably too busy for
the daemon thread (at min priority) to wake up and send the PropertyChangeEvent
message in time. I will add some preferences to ActiveMonitor to be able to
set the priority higher.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Peter Donald <do...@apache.org>.
On Tue, 21 Aug 2001 21:20, Jeff Turner wrote:
> I don't know what's going on here.. last week, I was experiencing just what
> you're talking about. Tests took >2 mins on an 800mhz Duron. Changing
> fork="true" to fork="false" made no difference.
hmmmm.
> Now, after having done a clean checkout, unsetting ANT_HOME, and running
> './build.sh test', it takes 27 secs. The XSLT bit takes under 2 secs.
I consider 29 secs waaaaaaaaaaaaaaaaaaaaay to long. My philosophy is
basically always run unit tests when compiling (excluding profiling or ones
that don't run on system - like ones with hardwired DB tables). So I consider
3 seconds pushing the bounds of acceptability ;)
ohwell
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Jeff Turner <je...@socialchange.net.au>.
I don't know what's going on here.. last week, I was experiencing just what
you're talking about. Tests took >2 mins on an 800mhz Duron. Changing
fork="true" to fork="false" made no difference.
Now, after having done a clean checkout, unsetting ANT_HOME, and running
'./build.sh test', it takes 27 secs. The XSLT bit takes under 2 secs.
Btw, the following tests currently fail:
testSubstituteErrorFile "file:src/test/test.xml" not found.
testActiveMonitorFailure "File not changed"
--Jeff
On Tue, Aug 21, 2001 at 08:39:03PM +1000, Peter Donald wrote:
> Hi,
>
> Could someone who knows junit do the following. For some reason the tests run
> ungodly slow. I suspect it is because it is forking the JVm and then doing
> lots of work with XML and then XSL a bit later. While this is nice if you
> want to generate reports etc it is no good for normal development. So there
> has to be someway where none of this stuff reports/results etl al is
> generated and everything is done in JVM. So if so could someone do it.
>
> --
> Cheers,
>
> Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> > From the JUnit FAQ:
> > ----------------------------------------------------------------
> > Wrap the top level suite in a subclass of TestSetup.
> > Here is a sample AllTests.suite() method:
> >
> > public static Test suite() {
> > TestSuite suite= new TestSuite();
> > ...add your tests and suites here...
> > TestSetup wrapper= new TestSetup(suite) {
> > public void setUp() {
> > oneTimeSetUp();
> > }
> > };
> > return wrapper;
> > }
>
> Yes, but with we are not using TestSuite under ANT, right?
Actually it works either way. The TestRunner in the JUnit
Ant task will try to treat EVERY class in its fileset as a
Test. That includes TestCase, TestSuite, and even inner classes
if you are not careful. You can use TestDecorators, TestSuites,
whatever you want.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by giacomo <gi...@apache.org>.
On Tue, 21 Aug 2001, Berin Loritsch wrote:
> giacomo wrote:
> >
> > On Tue, 21 Aug 2001, Berin Loritsch wrote:
> >
> > > Peter Donald wrote:
> > > >
> > > > On Tue, 21 Aug 2001 22:58, Berin Loritsch wrote:
> > > > > Changing the "fork" attribute to false causes the RMI Context tests to
> > > > > fail. This is due to the fact that it is trying to bind to a port that is
> > > > > already open.
> > > >
> > > > Hmm .. I thought I wrote it properly ;/ Oh well I will try to fix that so we
> > > > can do it in JVM.
> > >
> > > The biggest conceptual change is that setUp() and tearDown() is called around
> > > EACH test*() method. Testlet had one initialize() and one dispose() that was
> > > called for the life of the testlet class. JUnit calls setUp() and tearDown()
> > > for each test method.
> > >
> > > There is a way to do once only initialization/teardown, but it is a little
> > > convoluted--and should be done within our AvalonTestCase.
> >
> > I'm +1 for a one time initialize/dispose procedure. I haven't looked
> > into the code of the TestCase class but can we overrite some methods to
> > achieve it using a isInitialized variable or so?
>
> From the JUnit FAQ:
> ----------------------------------------------------------------
> Wrap the top level suite in a subclass of TestSetup.
> Here is a sample AllTests.suite() method:
>
> public static Test suite() {
> TestSuite suite= new TestSuite();
> ...add your tests and suites here...
> TestSetup wrapper= new TestSetup(suite) {
> public void setUp() {
> oneTimeSetUp();
> }
> };
> return wrapper;
> }
Yes, but with we are not using TestSuite under ANT, right?
Giacomo
>
----------------------------------------------------------------
>
> (http://junit.sourceforge.net/doc/faq/faq.htm#How do I run setup code only once)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
>
> On Tue, 21 Aug 2001, Berin Loritsch wrote:
>
> > Peter Donald wrote:
> > >
> > > On Tue, 21 Aug 2001 22:58, Berin Loritsch wrote:
> > > > Changing the "fork" attribute to false causes the RMI Context tests to
> > > > fail. This is due to the fact that it is trying to bind to a port that is
> > > > already open.
> > >
> > > Hmm .. I thought I wrote it properly ;/ Oh well I will try to fix that so we
> > > can do it in JVM.
> >
> > The biggest conceptual change is that setUp() and tearDown() is called around
> > EACH test*() method. Testlet had one initialize() and one dispose() that was
> > called for the life of the testlet class. JUnit calls setUp() and tearDown()
> > for each test method.
> >
> > There is a way to do once only initialization/teardown, but it is a little
> > convoluted--and should be done within our AvalonTestCase.
>
> I'm +1 for a one time initialize/dispose procedure. I haven't looked
> into the code of the TestCase class but can we overrite some methods to
> achieve it using a isInitialized variable or so?
>From the JUnit FAQ:
----------------------------------------------------------------
Wrap the top level suite in a subclass of TestSetup.
Here is a sample AllTests.suite() method:
public static Test suite() {
TestSuite suite= new TestSuite();
...add your tests and suites here...
TestSetup wrapper= new TestSetup(suite) {
public void setUp() {
oneTimeSetUp();
}
};
return wrapper;
}
----------------------------------------------------------------
(http://junit.sourceforge.net/doc/faq/faq.htm#How do I run setup code only once)
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by giacomo <gi...@apache.org>.
On Tue, 21 Aug 2001, Berin Loritsch wrote:
> Peter Donald wrote:
> >
> > On Tue, 21 Aug 2001 22:58, Berin Loritsch wrote:
> > > Changing the "fork" attribute to false causes the RMI Context tests to
> > > fail. This is due to the fact that it is trying to bind to a port that is
> > > already open.
> >
> > Hmm .. I thought I wrote it properly ;/ Oh well I will try to fix that so we
> > can do it in JVM.
>
> The biggest conceptual change is that setUp() and tearDown() is called around
> EACH test*() method. Testlet had one initialize() and one dispose() that was
> called for the life of the testlet class. JUnit calls setUp() and tearDown()
> for each test method.
>
> There is a way to do once only initialization/teardown, but it is a little
> convoluted--and should be done within our AvalonTestCase.
I'm +1 for a one time initialize/dispose procedure. I haven't looked
into the code of the TestCase class but can we overrite some methods to
achieve it using a isInitialized variable or so?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> On Tue, 21 Aug 2001 22:58, Berin Loritsch wrote:
> > Changing the "fork" attribute to false causes the RMI Context tests to
> > fail. This is due to the fact that it is trying to bind to a port that is
> > already open.
>
> Hmm .. I thought I wrote it properly ;/ Oh well I will try to fix that so we
> can do it in JVM.
The biggest conceptual change is that setUp() and tearDown() is called around
EACH test*() method. Testlet had one initialize() and one dispose() that was
called for the life of the testlet class. JUnit calls setUp() and tearDown()
for each test method.
There is a way to do once only initialization/teardown, but it is a little
convoluted--and should be done within our AvalonTestCase.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Peter Donald <do...@apache.org>.
On Tue, 21 Aug 2001 22:58, Berin Loritsch wrote:
> Changing the "fork" attribute to false causes the RMI Context tests to
> fail. This is due to the fact that it is trying to bind to a port that is
> already open.
Hmm .. I thought I wrote it properly ;/ Oh well I will try to fix that so we
can do it in JVM.
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Excalibur Junit
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Quoting Peter Donald <do...@apache.org>:
>
> > Hi,
> >
> > Could someone who knows junit do the following. For some reason the
> > tests run
> > ungodly slow. I suspect it is because it is forking the JVm and then
> > doing
> > lots of work with XML and then XSL a bit later. While this is nice if
> > you
> > want to generate reports etc it is no good for normal development. So
> > there
> > has to be someway where none of this stuff reports/results etl al is
> > generated and everything is done in JVM. So if so could someone do it.
>
> There are several options. First you can comment out the formatter element in
> the junit task. This will reduce test time (on my machine) from 41 secs. to 23
> secs. on the excalibur repository. Next you can change the fork="true" attribute
> to false on the junit element. But then the log messages don't gets onto the
> console but you still see which tests failed. This reduces the to to 9 secs.
Basically, it will be changing the formatter from "xml" to "plain". The
other step is to comment out junitreport task because it has no XML files to
parse. Parsing only takes a couple of seconds if you are using Xalan 2.2+.
Changing the "fork" attribute to false causes the RMI Context tests to fail.
This is due to the fact that it is trying to bind to a port that is already
open.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org