[
https://issues.apache.org/jira/browse/DERBY-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218217#comment-13218217
]
Kristian Waagan commented on DERBY-5382:
----------------------------------------
I'm not sure it's any better, but an alternative is to use a change database
decorator in the forked process. I'm doing this in the "modernized"
compatibility test, but it requires a little more infrastructure and you still
have to pass the database name as a system property.
If you commit the patch, I'll see if it works well in my scenario too (I'm
doing some more configuration so I'm not sure if it counts as a default
TestConfiguration yet).
To me your approach seems better for simple test cases like those being run
here, since you don't have a suite method. It appears to me the -m option is
incompatible with a lot of tests, but then I don't know how it's implemented
(i.e., does it still run the suite method, where many tests get their setup
from, and filter out the unwanted test cases afterwards?)
> Convert existing harness recovery tests to JUnit tests
> ------------------------------------------------------
>
> Key: DERBY-5382
> URL: https://issues.apache.org/jira/browse/DERBY-5382
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Siddharth Srivastava
> Assignee: Siddharth Srivastava
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5382.diff, DERBY-5382_2.diff, d5382.patch
>
>
> Existing harness recovery tests need to be converted to JUnit tests. A
> framework as designed in Derby-4249 can be used for this purpose.
> Tests to be converted:
> a) oc_rec1
> b) oc_rec2
> c) oc_rec3
> d) oc_rec4
> These recovery tests run in coordination. The test oc_rec1 creates a table,
> inserts and then deletes rows from it and commit it which is followed by a
> series of insertion of rows in the existing table in oc_rec2, oc_rec3 and
> oc_rec4. The tests oc_rec2 and oc_3 also create table and insert, delete,
> compress rows in it and leave the table thus produced in committed or
> uncommitted state which is tested by the next corresponding test (oc_rec3 for
> oc_rec2, oc_rec4 for oc_rec3) for recovery.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
