On 10/26/06, Nicolas <[EMAIL PROTECTED]> wrote:
Hi Alexandru,
Test NG is indeed an excellent idea. I will have a close look at it.
... and the help on using it is guaranteed ;-)
The next step is I think to define the test suite.
Currently we have found to check for:
1/ concurrencies
2/ stress test
3/ JCR test suite
Any other ideas?
I am not sure what do you mean by the above. I think the suite should contain:
- insert tests
- retrieve tests
- fetch tests
- query tests
From this we can easily create load + stress tests. I think we can
start looking at the current available tests (maybe Jackrabbit
committers will help us identify the aboves) and then move them little
by little.
Here is an example (considering that in TestNG you can easily pass
parameters to tests and so on):
initial test (existing test - I assume JUnit test):
public void testCreateNodeTest() {
// node creation test
}
From this one we can extract a common method (that will be invoked by
load or stress test):
public void createNodeTest(int numberOfNodes) {
}
Then, load test:
@Test
@Parameters({"createNumberOfNodes"})
public createNodesLoadTest(int numberOfNodes) {
// tracking code
createNodeTest(numberOfNodes);
}
and the stress test:
@Test(invocationCount=50, threadPoolSize=25)
@Parameters({"createNumberOfNodes"})
public createNodesLoadTest(int numberOfNodes) {
// tracking code
createNodeTest(numberOfNodes)
}
If we want this refined then we can start refactoring the measurement
code into @Before/@After methods.
Does this make any sense to you?
./alex
--
.w( the_mindstorm )p.
TestNG co-founder
EclipseTestNG Creator
BR,
Nico
my blog! http://www.deviant-abstraction.net !!
