db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1764) Rewrite stress.multi as a JUnit test
Date Thu, 12 Jun 2008 21:58:45 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604657#action_12604657

Kathey Marsden commented on DERBY-1764:

Thanks Erlend at a great first effort for converting stress.multi. Myrna and I had a look
together and this is what we came up with.  

- need Apache header.
- Keep lines to 80 characters.
- assuming timing is in todo list.
- Maybe we should move the junit test out to functionTests/tests/multi and have a separate
- Maybe rename to be StressMultiTest to match junit convention.
- SQL Exceptions e.g. in setup() should be thrown or accumulated and not just printed to std
- To keep your debug statements you can use BaseTestCase.println() and they will print out
with derby.tests.debug set to true.
- add SystemPropertyTestSetup to setup derby properties from the test (in run__derby.properties)
- THREADS and MINUTES should be static.
- fields should either nulled out with teardown or be changed to local variables to avoid
them consuming memory after the test runs.
- in setup() Statement s = getConnection().createStatement(); can just be Statement s = createStatement()
- I don't think we should interupt the the threads on error.  I think instead we can set a
completed flag and let the run method check for that and have the current operation complete.
That way we will avoid potentially running into DERBY-151
- You probably have it planned, but we seem to be missing some of the cases from the original
test, createy.sql, createz.sql, insert2.sql, update2.sql, selectmain2.sql.
- eventually need to add network server run, and encryption run.
- As for the weights I looked at this for a little while and am not quite sure how to map
to the same percentages.  Before we had 
			caseNum = (int)((java.lang.Math.random() * 1311) % numCases);
			testCase = (mtTestCase)cases.elementAt(caseNum);
		while (testCase.grab() == false);

Where grab() returned true weight percentage of the time and our weights did not add up to
100. Now we just want to use straight percentages which I think is fine.  Question is how
do we map the old weights to the correct percentage.

I feel like this is some high school math problem I can't figure out. Input from others would
be welcome.
- As for the build.xml file I think that once you move the test copying one of the existing
junit directory build.xml files and modifying it will be more straight forward.  (The current
build.xml that you have will make the encryption and derbynetclient runs of stress.multi fail.
Myrna understands why)

- It would be good if others could look at the test on the next round of review.  This is
an important test so it is crucial to get the conversion right.

Keep up the good work.


> Rewrite stress.multi as a JUnit test
> ------------------------------------
>                 Key: DERBY-1764
>                 URL: https://issues.apache.org/jira/browse/DERBY-1764
>             Project: Derby
>          Issue Type: Test
>          Components: Test
>            Reporter: Knut Anders Hatlen
>            Assignee: Erlend Birkenes
>         Attachments: DERBY-1764-Review.diff
> Currently, stress.multi consists of a number of sql scripts that are run in ij. It often
fails with cryptic error messages, and since it uses ij, there is often no stack trace. It
would be very useful to rewrite the test in JUnit so that we can get better error messages
and stack traces when it fails.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message