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 "Ole Solberg (JIRA)" <ji...@apache.org> on 2007/02/09 16:17:05 UTC
[jira] Created: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Convert compatibility/testScript.xml to JUnit
---------------------------------------------
Key: DERBY-2316
URL: https://issues.apache.org/jira/browse/DERBY-2316
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.3.0.0
Environment: All
Reporter: Ole Solberg
Assigned To: Ole Solberg
Priority: Minor
I have started converting compatibility/testScript.xml to JUnit to
1) be able to more dynamically specify which combinations to test,
2) get standard JUnit reports from the test, and
3) more easily include the compatibility test in the regression test runs.
I plan to use a property file (patterened after the current ant.property file for
the compatibility test), to specify jvm and derby library locations.
With the growing number of jvm and derby versions I also think that it should be
possible to specify a number of different kinds of compatibility test combinations,
for example:
a) the current way, which is all combinations of derby and jvm on both
server and client. [(derbys*jvms)*(derbys*jvms)]
b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485029 ]
Rick Hillegas commented on DERBY-2316:
--------------------------------------
Thanks for this improvement, Ole! Replacing the compatibiltiy driver with a JUnit program will make it easier to add new vms and derby revs to the tested combinations. I have committed this first slug of work at subversion revision 523505.
I have some suggestions for further improvements:
1) I found that I had to create a subdirectory named "system" in order for the tests to run. I think that the test should do this for me. If for some reason that is not possible, then I think that the javadoc should explain that this preliminary step is needed.
2) I think that the javadoc should explain that you can get verbose output by setting -Ddrb.tests.debug=true. Later on, we should change this verbose flag to be the same one used by the other JUnit tests, viz., derby.tests.debug.
3) It would be great to see some more defensive coding which fails the tests early if the environmental variables in compatibilitytest.properties point at garbage. I believe that the old ant harness does this kind of checking. I started out with a typo in the path to my junit.jar and this caused the tests to fail and leave a directory of empty diagnostic files. It took a while to figure out what was broken.
4) It would be nice if this test could follow the excellent pattern now used by the JUnitized upgrade tests, i.e., require that the old releases live under a directory pointed to by derbyTesting.oldReleasePath. That would eliminate a number of fragile variables in compatibilitytest.properties.
Thanks!
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assigned To: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ole Solberg updated DERBY-2316:
-------------------------------
Attachment: derby-2316_v1.example_compatibilitytest.properties
derby-2316_v1.diff.txt
First version of java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/CompatibilityCombinations.java which is intended as a replacement for java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/testScript.xml.
CompatibilityCombinations.java reads paths for Derby versions and Jvm versions from the file 'compatibilitytest.properties' in '${user.dir}'.
An example of 'compatibilitytest.properties' is included in the patch.
Test results are reported as
Attempted 'embedded vs. network client' tests: 9, OK: 9, Failed: 0, Time: 54.0 seconds
Attempted 'server - network client' tests: 324, OK: 324, Failed: 0, Time: 1132.0 seconds
More detailed reports are found in '${user.dir}/system' in files following this name pattern:
1. Embedded_compatDB_summary.log
which is a summary of
1.n Embedded_TrunkVMj15lib_vs_ClientVM-j15lib_clientTrunk report files
and
2. ServerClient_compatDB_summary.log
which is a summary of
2.m ServerVM-j16lib_server10.1.2.1_vs_ClientVM-j14lib_clientTrunk report files
I ran
'java -Djava.security.policy="<NONE>" junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations'
using derby-2316_v1.example_compatibilitytest.properties as compatibilitytest.properties
on Linux 2.6.17-1.2142_FC4.
Result:
Attempted 'embedded vs. network client' tests: 9, OK: 9, Failed: 0, Time: 54.0 seconds
Attempted 'server - network client' tests: 324, OK: 324, Failed: 0, Time: 1132.0 seconds
CompatibilityCombinations.java still contains lots of 'DEBUG' statements and the javadoc could probably be expanded...
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assigned To: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ole Solberg updated DERBY-2316:
-------------------------------
Attachment: derby-2316_v2.diff.txt
The attached patch(derby-2316_v2.diff.txt) changes '..../tests/junitTests/compatibility/CompatibilityCombinations.java' to allow other testsuites than jdbcSuite (org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite) to be used in testing Derby client version vs. Derby server version compatibility.
The testsuite to be used is now specified in the file 'compatibilitytest.properties'.
I need this functionality specifically in testing BlobClob client version vs. server version compatibility using '..../tests/jdbcapi/BlobClob4BlobTest.java' in the CompatibilityCombinations framework.
I have also taken care of Rick's suggestion for further improvements 1).
The patch has been tested running
java -Xmx256m -Djava.security.policy="<NONE>" junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilityCombinations .
----------
I will submit the neccessary modifications to run '..../tests/jdbcapi/BlobClob4BlobTest.java' in the CompatibilityCombinations framework in a separate JIRA.
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502740 ]
Ole Solberg commented on DERBY-2316:
------------------------------------
Yes, the plan is definitly to make these tests like the other new JUnit tests, and to follow the pattern from the upgrade tests with respect to how old release jars are found.
It appears I will have time to work on this now.
For the first version of '..../tests/jdbcapi/BlobClob4BlobTest.java' in the CompatibilityCombinations framework I intend to use the current version of "CompatibilityCombinations". This is something I have running in my sandbox now, and should not need rework when modifying the CompatibilityCombinations framework.
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-2316:
--------------------------------------
Derby Info: (was: [Patch Available])
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt, derby-2316_v3.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509217 ]
Knut Anders Hatlen commented on DERBY-2316:
-------------------------------------------
The patch looks good to me.
Committed revision 552051.
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt, derby-2316_v3.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546775 ]
Dyre Tjeldvoll commented on DERBY-2316:
---------------------------------------
I see that a patch was committed in June. Can we resolve/close this issue now?
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.1.4
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt, derby-2316_v3.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ole Solberg updated DERBY-2316:
-------------------------------
Attachment: derby-2316_v3.diff.txt
Attaching derby-2316-v3.diff.txt replacing derby-2316-v2.diff.txt.
Identical to derby-2316-v2.diff.txt but with the addition of modifications in
testOutput(): extracting both OK and Failure/Error info from each test combination
into summary report.
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt, derby-2316_v3.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502427 ]
Daniel John Debrunner commented on DERBY-2316:
----------------------------------------------
Are there still plans to make these tests like any other (new) Junit test?
At least some default setup that would run using the old release jars like the upgrade test.
The tests could allow more options, but some easy to run case would be great.
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2316) Convert compatibility/testScript.xml to
JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ole Solberg closed DERBY-2316.
------------------------------
Resolution: Fixed
I will create a new issue for further work to use old jars like the upgrade tests do.
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.1.4
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt, derby-2316_v3.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485096 ]
Ole Solberg commented on DERBY-2316:
------------------------------------
Thanks for reviewing and committing Rick!
I will follow up your suggestions for improvements.
Thanks!
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assigned To: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2316) Convert compatibility/testScript.xml
to JUnit
Posted by "Ole Solberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ole Solberg updated DERBY-2316:
-------------------------------
Derby Info: [Patch Available]
> Convert compatibility/testScript.xml to JUnit
> ---------------------------------------------
>
> Key: DERBY-2316
> URL: https://issues.apache.org/jira/browse/DERBY-2316
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Environment: All
> Reporter: Ole Solberg
> Assignee: Ole Solberg
> Priority: Minor
> Attachments: derby-2316_v1.diff.txt, derby-2316_v1.example_compatibilitytest.properties, derby-2316_v2.diff.txt, derby-2316_v3.diff.txt
>
>
> I have started converting compatibility/testScript.xml to JUnit to
> 1) be able to more dynamically specify which combinations to test,
> 2) get standard JUnit reports from the test, and
> 3) more easily include the compatibility test in the regression test runs.
> I plan to use a property file (patterened after the current ant.property file for
> the compatibility test), to specify jvm and derby library locations.
> With the growing number of jvm and derby versions I also think that it should be
> possible to specify a number of different kinds of compatibility test combinations,
> for example:
> a) the current way, which is all combinations of derby and jvm on both
> server and client. [(derbys*jvms)*(derbys*jvms)]
> b) Current trunk client and jvms vs. all server derbys and jvms. [(1*jvms)*(derbys*jvms)]
> c) All clients and jvms vs. current trunk server and jvms. [(derbys*jvms)*(1*jvms)]
> d) Exact specification of the combinations to be tested. [(N*M)*(X*Y)]
> Which kind of test to run should be specified in the property file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.