geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Unit/Stress Tests
Date Tue, 03 Aug 2004 19:04:53 GMT
I think the reason our stress tests don't take very long, is we are 
limiting them because we don't want the build to take a long time.  I 
think once we remove this limitation the test time will grow and we 
will get actual stress testing.


On Aug 3, 2004, at 11:19 AM, David Jencks wrote:

> Before we jump off the cliff here, just how long do the stress tests 
> currently take?  I don't think it is a significant fraction of the 
> build time.  I recall trying this idea of isolating stress tests in 
> jboss builds and it turned into a real mess.  Noone likes maintaining 
> the test system, lets keep it as simple as possible.  I think setting 
> up damage control would be more useful.
> Also I have set up all the projects we are collectively involved in in 
> a single build environment
> (tranql, howl, geronimo, openejb, activemq).  I suggest we set up 
> something like this to be run by dc.
> david jencks
> On Aug 3, 2004, at 9:10 AM, Dain Sundstrom wrote:
>> On Aug 3, 2004, at 7:41 AM, Alan D. Cabrera wrote:
>>> 1) There is a maven build flag that lets builds complete, regardless 
>>> of
>>> the tests' completion status.  IMHO, if something breaks for them, 
>>> then
>>> something is broken for their configuration and they should know 
>>> about
>>> it; this is the raison d'etre of unit tests.  People who cannot 
>>> handle
>>> this should be directed to pre-built jars, though I suspect that most
>>> responsible shops will run the unit tests on their target platforms.
>>> However, if it takes a long time, then this is a different matter; I
>>> like David Jenks' idea of running smaller, quicker, tests.
>> Although that is an good idea, I think the implementation is much 
>> more difficult.  Until we have parameterized stress tests, I'd say 
>> the best plan is to isolate stress tests and only run them during the 
>> nightly build.
>> -dain

View raw message