--- In junitperf@y..., Mike Clark <mike@c...> wrote:
> I think I understand your intent. You can do something like this:
>
> protected static Test makeLoadTest() {
> int users = 1;
> int iterations = 1;
>
> Test loadTest = new LoadTest(JUnitTestAll.suite(), users, iterations);
> return loadTest;
> }
>
> Notice, however, that a TestFactory isn't used here so you may end up
> with concurrency issues in test fixtures. There's no way to use a
> TestFactory on a suite containing multiple tests.
Thank you.

> But what puzzles me is why you'd want to run your entire suite of tests
> en masse as load tests. Instead, I'd recommend picking certain test
> case methods that have quantifiable performance and scalability
> requirements, then use JUnitPerf to test those. That's generally a
> better use of your time and JUnitPerf was designed to help you in these
> situations.
I was involved in the implementation of one API. All seemed to be fine with
JUnit tests and, even, with JUnitPerf tests (but not very well thought tests).

But when using this API in production environment, in some circumstances, one
strange error arose (this indicates that the unitary tests chosen for JUnitPerf
tests, wasn't the good ones).

By inspecting the code (and a little lucky), the problem was found and fixed...
but, usually, this doesn't work. If you know what you are looking for, it's
simpler to find out it.

After that, I was trying to figure out what would be happen if I were running
performance (and general) tests in an authomated way, for the problems to arise,
instead of waiting for them to be reported... or have a hard work looking for
them (and having a lucky day to build the right performance tests).

In fact, I had a very complete set of unitary tests but didn't discover the
problem. If I could run all my unitary tests in a parallel way, would the
problem be (authomatically) exhibited? If so, I would adopt a new habit: to run
performance unitary tests, besides of my unitary tests, so some unexpected
problems get discoverd :-)

Summarizing, I was trying to apply the same philosophy of unitary tests to
performance unitary tests: to run all the tests, all the time to find the errors
you don't expect.

Once more, thank you very much.