db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5382) Convert existing harness recovery tests to JUnit tests
Date Tue, 28 Feb 2012 14:23:46 GMT

    [ 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:
>         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


View raw message