river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject RE: jtreg tests
Date Tue, 21 Apr 2009 20:42:16 GMT
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

View raw message