geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject RE: Unit/Stress Tests
Date Tue, 03 Aug 2004 12:41:44 GMT
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.

2) +1


> -----Original Message-----
> From: David Blevins []
> Sent: Monday, August 02, 2004 11:45 PM
> To:
> Subject: Unit/Stress Tests
> In my mind stress tests and unit tests are different things.  Stress
> tests should not be run with the unit tests as part of a regular
> build.  They would be in the same src/test dir, but everything
> matching * would be excluded.  We should be running
> these with some separate maven goal like 'maven test:stress' or
> something similar (a similar thing could perhaps be done with the
> integration tests in openejb, 'maven test:integration').
> My motivation is two fold.
> One, the stress tests slow the build down so much that it's clear
> people are trying to get by without having to build
> everything--frequently breaking builds is a tell-tale sign.
> Two, if we are going to do stress tests, which is good, we should
> really go all out and hammer the server.  I'm talking about tests that
> nail the server for like a half an hour filling up pools, trashing
> memory, stretching the thread count, and generally pushing things to
> their limit.
> We already do nightly build/test runs on several machines, it would be
> fairly trivial to setup a machine to run the stress tests as well.
> Though it would be better to use dedicated hardware for these as the
> resource consumption would go beyond responsible usage of boxes
> performing other critical tasks.
> Thoughts?
> -David

View raw message