You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2011/08/17 20:42:27 UTC
[jira] [Updated] (DERBY-4249) Create a simple store recovery test
in JUnit
[ https://issues.apache.org/jira/browse/DERBY-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-4249:
----------------------------------
Attachment: derby4249_secmgr_diff.txt
Thank you Siddharth for the patch. I think it is looking very good as a model for the recovery tests.
I updated the patch with a few changes which I am attaching as derby4249. I enabled security manager by adding the needed lines to the policy file and fixed a preexisting problem with the output when the launched method fails so that it prints the expected output strings and not just the array reference.
I also added a CleanDatabaseTestSetup decorator so that the schema objects get cleaned up. If nobody objects I will commit after I run some tests.
> Create a simple store recovery test in JUnit
> --------------------------------------------
>
> Key: DERBY-4249
> URL: https://issues.apache.org/jira/browse/DERBY-4249
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.6.1.0
> Reporter: Kathey Marsden
> Assignee: Siddharth Srivastava
> Priority: Minor
> Attachments: d4249.diff, d4249_1.diff, d4249_2.diff, d4249_3.diff, derby4249.diff, derby4249.diff, derby4249_secmgr_diff.txt
>
>
> It would be good to be able to start converting the store recovery tests or at least be able to write new recovery tests in JUnit. We could start by writing a simple recovery test just to establish the framework. The test should.
> - Connect, create a table, commit and shutdown the database.
> - fork a jvm, add one row, commit, add another row, exit the jvm.
> - Reconnect with the first jvm and verify that the first row is there and the second is not.
> I guess the main thing to decide is how to spawn the second jvm and check results. I tend to think the second jvm should actually execute another JUnit test, verify the exit code (assuming a failed test has a non-zero exit code) and then put the output in the fail assertion if it fails so it shows up in the report at the end of the Suite execution. I think we could create a test runner that takes a class and a specific test to run instead of the whole suite, so we could keep our methods consolidated in a single class for the test, but all pure conjecture at this point. I'll have to give it a try, but wanted to first see if folks thought this was a reasonable approach.
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira