Derby
  1. Derby
  2. DERBY-5475

Formalize use of old Derby distributions in tests

    Details

    • Type: Improvement Improvement
    • Status: In Progress
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: None
    • Component/s: Test
    • Labels:
      None

      Description

      Some types of tests need old Derby distributions to perform the required actions. Currently this includes the upgrade test and the compatibility test.
      Instead of each test dealing with this in their own way, there should be support for accessing old Derby distributions in the test framework.

      I propose to add a Derby distribution repository in the test framework, with the following guidelines and changes:
      o keep it as simple as possible, which suggests it is the users responsibility to keep the repository updated
      o compatibility with the existing derbyTesting.oldReleasePath property
      o make the tests requiring old distributions fail if there are no distributions available
      o establish a default location where the test framework will look for old distributions if derbyTesting.oldReleasePath is unspecified
      o the repository should not incur any costs when not used by the test(s) being run

      In favor of simplicity the repository will not download releases itself. The user has to keep the repository contents up-to-date, which is as simple as running 'svn up' each time a new Derby release is published. It is unclear if, and what, the repository and/or relevant tests should do if the repository is outdated. It seems useful to allow the user to make available only a subset of the distributions, but maybe printing a warning is helpful to remind developers that their repository is stale.

      Another related issue, which will only be relevant some time in the future, is whether a test framework of version X should make available distributions of version X+n. Currently I'm leaning towards not doing that, but haven't really looked into it.

      See also thread on derby-dev: http://db.markmail.org/thread/44uyusa726cwjuk2

      1. derby-5475-4a-less_exceptions_and_expose.diff
        6 kB
        Kristian Waagan
      2. derby-5475-3a-repository.diff
        23 kB
        Kristian Waagan
      3. derby-5475-2a-rename_and_cleanup.stat
        0.3 kB
        Kristian Waagan
      4. derby-5475-2a-rename_and_cleanup.diff
        7 kB
        Kristian Waagan
      5. derby-5475-1b-DerbyVersion.diff
        23 kB
        Kristian Waagan
      6. derby-5475-1a-DerbyVersion.diff
        21 kB
        Kristian Waagan

        Issue Links

          Activity

          Hide
          Myrna van Lunteren added a comment -

          Kristian, is there still more work to come under this JIRA?

          Show
          Myrna van Lunteren added a comment - Kristian, is there still more work to come under this JIRA?
          Hide
          Kristian Waagan added a comment -

          Committed patch 4a to trunk with revision 1352498.

          Show
          Kristian Waagan added a comment - Committed patch 4a to trunk with revision 1352498.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 4a, which removes some leftover throws-clauses and changes the exception handling in one case.
          It also exposes the release repository through a static method in TestConfiguration.

          Show
          Kristian Waagan added a comment - Attaching patch 4a, which removes some leftover throws-clauses and changes the exception handling in one case. It also exposes the release repository through a static method in TestConfiguration.
          Hide
          Kristian Waagan added a comment -

          Committed patch 3a to trunk with revision 1330751.
          The next step is probably to rewrite one of the tests to start using the repository, and to make it available in the test framework.
          I do plan to remove the code that downloads the JARs from Apache because. In my opinion downloading the JARs each time you run the test needing them is a waste of resources. Instead the developer should download them once and then update the local repository, which is as simple as typing 'svn up', at regular intervals or explicitly when a new release happens.

          As for more functionality, I'm considering moving the handling of derbyTesting.oldVersionsPath into ReleaseRepository. I have no feel for how much this is being used, but it does allow for a solution where the configuration can be relatively easy scripted from a shell or similar.

          Show
          Kristian Waagan added a comment - Committed patch 3a to trunk with revision 1330751. The next step is probably to rewrite one of the tests to start using the repository, and to make it available in the test framework. I do plan to remove the code that downloads the JARs from Apache because. In my opinion downloading the JARs each time you run the test needing them is a waste of resources. Instead the developer should download them once and then update the local repository, which is as simple as typing 'svn up', at regular intervals or explicitly when a new release happens. As for more functionality, I'm considering moving the handling of derbyTesting.oldVersionsPath into ReleaseRepository. I have no feel for how much this is being used, but it does allow for a solution where the configuration can be relatively easy scripted from a shell or similar.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 3a, which adds two classes:

            • junit/DerbyDistribution
              A class representing a Derby distribution on disk. Has a set of convenience methods to work with the distribution, i.e. getting the paths to various JAR-files and the version.
              It only supports distributions based off JARs. It is not problematic to add support for classes-based distributions, but using such distributions in tests is more complicated due to various classpath issues. For instance, some tests require that you only add the client code. I suspect further problems like classpath shadowing and possibly sealing violations.
            • junit/ReleaseRepository
              Builds a list of distributions found in a directory on disk.
              This repository does nothing to fetch or verify that the directory on disk contains a recent set of releases. It's up to the user to keep the directory updated, and up to the tests using the repository to require specific releases etc.
              The repository will look in a default location ($HOME/.derbyTestingReleases), but this can by overridden by specifying derbyTesting.oldReleasePath. That property is already used by existing tests.

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Attaching patch 3a, which adds two classes: junit/DerbyDistribution A class representing a Derby distribution on disk. Has a set of convenience methods to work with the distribution, i.e. getting the paths to various JAR-files and the version. It only supports distributions based off JARs. It is not problematic to add support for classes-based distributions, but using such distributions in tests is more complicated due to various classpath issues. For instance, some tests require that you only add the client code. I suspect further problems like classpath shadowing and possibly sealing violations. junit/ReleaseRepository Builds a list of distributions found in a directory on disk. This repository does nothing to fetch or verify that the directory on disk contains a recent set of releases. It's up to the user to keep the directory updated, and up to the tests using the repository to require specific releases etc. The repository will look in a default location ($HOME/.derbyTestingReleases), but this can by overridden by specifying derbyTesting.oldReleasePath. That property is already used by existing tests. Patch ready for review.
          Hide
          Kristian Waagan added a comment -

          Patch 2a renames DerbyVersionSimple to Version to indicate that it isn't tied speicifally to a Derby version.
          Renamed method 'atLeastAs' to 'atLeast', and did some other minor changes.

          Committed to trunk with revision 1245349.

          Show
          Kristian Waagan added a comment - Patch 2a renames DerbyVersionSimple to Version to indicate that it isn't tied speicifally to a Derby version. Renamed method 'atLeastAs' to 'atLeast', and did some other minor changes. Committed to trunk with revision 1245349.
          Hide
          Kristian Waagan added a comment -

          Fixed incorrect class name in license header in DerbyVersionTest with revision 1195481.

          Show
          Kristian Waagan added a comment - Fixed incorrect class name in license header in DerbyVersionTest with revision 1195481.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1b, which makes DerbyVersion use the Utilities.split method instead of String.split (JSR169 limitation). Added a test case for the parseVersionString method.

          Committed patch 1b to trunk with revision 1195449.
          I will incorporate any after-commit comments in coming patches (there is no code using these classes yet).

          Show
          Kristian Waagan added a comment - Attaching patch 1b, which makes DerbyVersion use the Utilities.split method instead of String.split (JSR169 limitation). Added a test case for the parseVersionString method. Committed patch 1b to trunk with revision 1195449. I will incorporate any after-commit comments in coming patches (there is no code using these classes yet).
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1a, which adds the following classes:
          o junit.DerbyVersion
          main class representing a Derby version. Has methods for comparing versions against each other. Holds major, minor, fixpack and point levels/versions.
          I decided to add all officially released versions as constants (code needing to use non-official/-released versions should create their constants elsewhere).
          The methods are inspired by existing use in the compatibility and the upgrade tests. A little more functionality may be added depending on what the UpgradeTrajectoryTest needs.
          There are a few version classes around (some as inner classes), hopefully this one can be used in all cases.

          o junit.DerbyVersionSimple
          Holds only major.minor levels. Introduced for compatibility, may be removed later on.

          o unitTests.junit.DerbyVersionTest
          Basic test for the comparison methods.

          Also added the new test to unitTests.junit._Suite.
          All the code is currently unused. The coming release repository will use it, so will the rewritten compatibility test (DERBY-2076). I will also make changes to the upgrade tests.

          Patch 1a ready for review.

          Show
          Kristian Waagan added a comment - Attaching patch 1a, which adds the following classes: o junit.DerbyVersion main class representing a Derby version. Has methods for comparing versions against each other. Holds major, minor, fixpack and point levels/versions. I decided to add all officially released versions as constants (code needing to use non-official/-released versions should create their constants elsewhere). The methods are inspired by existing use in the compatibility and the upgrade tests. A little more functionality may be added depending on what the UpgradeTrajectoryTest needs. There are a few version classes around (some as inner classes), hopefully this one can be used in all cases. o junit.DerbyVersionSimple Holds only major.minor levels. Introduced for compatibility, may be removed later on. o unitTests.junit.DerbyVersionTest Basic test for the comparison methods. Also added the new test to unitTests.junit._Suite. All the code is currently unused. The coming release repository will use it, so will the rewritten compatibility test ( DERBY-2076 ). I will also make changes to the upgrade tests. Patch 1a ready for review.

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development