Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 26 Jul 2011 06:49:09 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1632545149.6778.1311662949583.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (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:comment-tabpanel&focusedCommentId=13070975#comment-13070975 ] 

Knut Anders Hatlen commented on DERBY-4249:
-------------------------------------------

Some comments in addition to what Dag said:

- On the terminology: My understanding is that "fixture" refers to the fixed state created by the setUp() method, so it's not something one can launch. It would probably be clearer to call the method something like "assertLaunchedJUnitTestMethod".

- I think the assert method should throw any exceptions it encounters, not catch them and print them.

- Perhaps we could take advantage of the existing assertExecJavaCmdAsExpected() method? That method checks both the exit status and the presence of expected strings in the output, and it only prints the output from the nested test if it's not what we expected, so it would probably address Dag's first two comments. Something like this might work:

    String[] cmd = new String[] { "junit.textui.TestRunner", "-m", testMethod };
    assertExecJavaCmdAsExpected(new String[] { "OK (1 test)" }, cmd, 0);

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