river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Costers <jonathan.cost...@googlemail.com>
Subject Re: Build failed in Hudson: River-trunk #163
Date Wed, 22 Apr 2009 18:37:58 GMT
Op dinsdag 21-04-2009 om 15:52 uur [tijdzone -0400], schreef Peter
Jones:
> 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

Waw, thanks a lot for your explanation, Peter. It clears up a lot of
things for me :-)

So, do you think it would be useful to enable these tests in River? Are
they overlapping with the QA suite? Should we choose one or the other
framework? Or should we keep both?

Thanks again for your comments.
Jonathan



Mime
View raw message