Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Sat, 30 Jul 2011 15:36:09 +0000 (UTC)
From: "Siddharth Srivastava (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <765504377.20950.1312040169654.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-4249) Create a simple store recovery test
 in JUnit
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Siddharth Srivastava updated DERBY-4249:
----------------------------------------

    Attachment: derby4249.diff

Updated patch

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