I think that parameterizing the stress tests and running them in the
normal build at very low volume is a good idea. Then they can be run
also at high volume on a more dedicated machine. I could be wrong but
I think that starting and stopping kernels and xml manipulation takes
more test time than our current stress tests.
david jencks
On Aug 2, 2004, at 9:44 PM, David Blevins wrote:
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 *StressTest.java 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
