Uploaded image for project: 'River'
  1. River
  2. RIVER-304

Reactivate River jtreg tests

    XMLWordPrintableJSON

    Details

    • Type: Test
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: River_3.0.0
    • Component/s: build
    • Labels:
      None
    • Environment:

      JDK 1.5 or later with jtreg test suite http://www.openjdk.org/jtreg/

      Description

      From a recent discussion on river-dev:

      Peter Firmstone wrote:
      > Using the GPLv2 version of jtreg is ok as a platform requirement for the tests, we just can't distribute it with River.
      >
      > Peter Jones wrote:
      >> On Tue, Apr 21, 2009 at 06:27:18PM +0200, Jonathan Costers wrote:
      >>
      >>> Something a bit off-topic: the "jtreg tests" are mentioned in the
      >>> discussion you linked to. How do these differ from the other harness/QA
      >>> tests? I must say I haven't really looked at them deeply, but I did
      >>> notice them and that they are separate from the QA suite ...
      >>> For the moment the source just sits there .. Nothing is even compiled.
      >>> Would you be able to give some pointers?
      >>>
      >>
      >> Sure. They are written to be run with "jtreg", the test harness used
      >> for regression & unit tests for Sun's JDK. These days there is a
      >> version of jtreg available under GPLv2 as part of the OpenJDK project,
      >> here:
      >>
      >> http://www.openjdk.org/jtreg/
      >>
      >> The use of this test framework in addition to the primary Jini QA
      >> framework is historical: some of the APIs added to version 2.0 of the
      >> Jini starter kit-- such as JERI and the related security model,
      >> preferred classes, the configuration stuff-- were originally developed
      >> for the JDK, mostly under JSRs 76 & 78, and thus their implementations
      >> initially had tests written for the jtreg framework. When those APIs
      >> and implementations were moved to the Jini starter kit, those jtreg
      >> tests came with them, and some new tests in those areas continued to
      >> be added to this jtreg suite.
      >>
      >> The essential jtreg model is very simple: a test is a tagged class
      >> (source file) with a normal "main" method-- if that method completes
      >> normally, the test passes; if it throws an exception (or times out, or
      >> the JVM crashes...), the test fails. The jtreg goal was to set a very
      >> low barrier to move standalone test cases or example code into the
      >> framework. The framework does specify more options and nuances, but
      >> it's still pretty simple overall:
      >>
      >> http://www.openjdk.org/jtreg/tag-spec.txt
      >>
      >> which is quite nice for some things-- of course it doesn't have
      >> anything like the power of the Jini QA framework for testing of
      >> distributed services, etc. And the Jini jtreg suite has accreted an
      >> unfortunately somewhat ad hoc infrastructure library of its own, in
      >> the "qa/jtreg/testlibrary" directory. Also, I think that it still has
      >> a few assumptions about being run within Sun's internal network, like
      >> that certain services (a KDC?) are provided by certain host names.
      >>
      >> You just see source files because the harness is responsible for
      >> building them at test execution time. The jtreg implementation is
      >> built as a layer on top of the JavaTest framework (a much more complex
      >> test framework used for the JCK among other things), which has the
      >> same build-at-test-execution-time model. (This is nice in that
      >> breaking the compilation of one test doesn't prevent executing other,
      >> unaffected tests-- each test is isolated all the way to its source.)
      >>
      >> I'm not sure how the GPLv2 status of the jtreg implementation
      >> available through the OpenJDK project affects the ability to use it to
      >> run these tests for River. A nice aspect of the jtreg model's
      >> simplicity is that the test classes themselves do not need to link to
      >> or otherwise refer to any test framework APIs-- there are no such
      >> APIs. (In theory each of these tests can be run as is, with the right
      >> class paths and javac & java commands.) At one time the engineering
      >> lead for the Jini QA harness had prototyped adding support for
      >> jtreg-style tests to the Jini harness, and I think that he had gotten
      >> it more or less working, but that effort was dropped for reasons I
      >> can't recall-- although I would guess that it didn't seem like a
      >> priority at the time because jtreg itself was available internally.
      >>
      >> – Peter
      >>
      >>

        Attachments

        1. ant.html
          8 kB
          Peter Firmstone
        2. jtreg_stdout_errout.txt
          406 kB
          Peter Firmstone
        3. jtreg-20100827-JC.log
          37 kB
          Jonathan Costers
        4. jtreg-output-20090928-JC.tar.gz
          90 kB
          Jonathan Costers
        5. JTreport.tgz
          26 kB
          Peter Firmstone
        6. JTreport-jdk1.5-qatests-trunk.tgz
          14 kB
          Peter Firmstone
        7. JTwork.tgz
          1.01 MB
          Peter Firmstone
        8. JTwork-jdk5-qatests-trunk.tgz
          998 kB
          Peter Firmstone
        9. test-results6-oct-09.tgz
          1.21 MB
          Peter Firmstone

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                pfirmst Peter Firmstone
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: