[
https://issues.apache.org/jira/browse/DERBY-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067001#comment-13067001
]
Kathey Marsden commented on DERBY-4249:
---------------------------------------
Hi Siddharth,
I did not apply but looked briefly at why the process might not execute.
String[] cmd= new String[]{"java junit.textui.TestRunner -m
org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.launchRecoveryInsert"};
The individual arguments should be broken out into separate String array
elements and also java should not be included in what is passed to execJavaCmd
as the java executable is determined by execJavaCmd. I'd suggest you make that
change and then run the test with -Dderby.tests.debug=true and then execJavaCmd
will show exactly what it is trying to execute. You can then cut and paste that
into a shell to see what might be going wrong. You can also use
BaseTestCase.readProcessOutput to read the output and see what error is being
encountered. This method will probably be useful as well to get the output if
the process fails.
As an aside, ultimately you will want to pass the class and fixture into
assertLaunchedJUnitFixture() so it can be used generically.
> 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
>
>
> 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
