db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-514) Integrate upgrade tests into test suite
Date Wed, 12 Apr 2006 23:07:01 GMT
     [ http://issues.apache.org/jira/browse/DERBY-514?page=all ]

Deepa Remesh updated DERBY-514:

    Attachment: derby-514-patch3-v2.diff

Attaching a patch 'derby-514-patch3-v2.diff' for Andrews comments in derby-dev mail - http://www.nabble.com/Re%3A-jira-Updated%3A-%28DERBY-514%29-Integrate-upgrade-tests-into-test-suite-p3854692.html

This patch changes the build script to use a property which points to the location of old
jars. With this change, it should be possible to run the upgrade test using RunTest without
any additional command-line flags. 

For Andrew's comments:
* Changed the requirement for setting of derbyTesting.jar.path property. It needs to be set
only if we are running tests on a different machine where the source files are not available.
If we run tests from the machine where source files are available, the jars will e picked
up from tools/testing/derby.

* Added better error message for the class not found exceptions. 

* I had tried to make this run with classes folder. The problem is that we may need to keep
changing the metadata test in the older version to be able to test the upgrade. Currently,
we are using the test classes (derbyTesting.jar) from new version in all cases. This separation
is not possible when we use classes folder. I am not planning to work on this now. I am just
focussing to get this test into a suite.

Summary of patch:
* Changes the build to use a property derbyTesting.jar.path from ant.properties and use it's
value for the location of the jar files from previous release. This property has to be set
in ant.properties if the tests will be run on a non-development machine. If the test is run
on the machine where the svn source files are available, it is not required to set this property.
The jars checked into svn will be used.

* Updates building.txt with the information about new property

* During build, the new property will be read and used to set the property in the test properties
file. Currently, it sets a property in Upgrade_10_1_10_2_app.properties. This needs to be
generalized as more upgrade combinations will be tested. But I am having trouble doing it
in a separate property file as it does not get loaded by harness. I will continue to look
into this. 

* Changes UpgradeTester to use the new property. UpgradeTester finds out the location of old
and new jars and hence these need not be passed into the class.

* Adds better error reporting to UpgradeTester

Ran the upgrade test in following scenarios:

*  "derbyTesting.jar.path" property not set and jars checked out from svn into tools/testing/derby/10.1.
Test passed.

*  "derbyTesting.jar.path" property not set and jars not checked out from svn. Test failed
with message asking to check settings

*  "derbyTesting.jar.path" property set to a correct location. Test passed.

*  "derbyTesting.jar.path" property set to a wrong location. Test failed with message asking
to check settings

*  Ran the test using classes folder in class path . Test failed with message asking to check

Next step

* If this patch is okay, I'll submit the patch which adds a new suite with this test and make
it part of derbyall. I checked this has no problems when using RunSuite
* As Andrew suggested in DERBY-1049, "When the upgrade tests are in place and working, we
should commit the setting of this property to the repository so that all subversion clients
fetch the jars needed by the upgrade tests." - This will avoid the manual step of setting
svn:externals. As I mentioned previously, one small change from what is mentioned in DERBY-1049
is - Instead of mapping to derby/, we need to map it to derby/10.1 since we plan to
have tests only at {major version}.{minor version} level.

Please take a look at this patch. Thanks.

> Integrate upgrade tests into test suite
> ---------------------------------------
>          Key: DERBY-514
>          URL: http://issues.apache.org/jira/browse/DERBY-514
>      Project: Derby
>         Type: Test

>   Components: Test
>     Versions:,
>     Reporter: Kathey Marsden
>     Assignee: Deepa Remesh
>      Fix For:
>  Attachments: derby-514-buildfiles-v1.diff, derby-514-buildfiles-v1.status, derby-514-patch1-v1.diff,
derby-514-patch1-v1.status, derby-514-patch2-runtest-v1.diff, derby-514-patch2-runtest-v1.status,
derby-514-patch3-v1.diff, derby-514-patch3-v1.status, derby-514-patch3-v2.diff, derby-514-patch3-v2.status,
derby-514-patch4-sed.diff, derby-514-patch4-sed.status
> Currently there are no upgrade tests in the derbyAll suite.
> The upgrade tests java/testing/org/apache/derbyTesting are run by script and require
that the version to be tested by specified on the command line so that the classpath can be
> # runphases old_major old_minor old_engine new_engine
> #
> # e.g.
> #
> # runphases 10 0 c:/derby/ c:/derby/trunk/jars/sane
> Perhaps this script can be rewritten in Java using class loaders and  previous Derby
verssions such as 10.0 and 10.1 be checked in so that this testing can   be incorporated into
the derbyAll test suite.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message