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.
-dain
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
