I raised an issue in Jira when I first saw Peter's reply, I hope you
don't mind.
Who was the Engineering lead for the Jini test harness? Is it possible
the source code for adding support for jtreg-style tests to the Jini
harness is still available and could be donated to the River project for
reassessment?
I think its important we investigate the jtreg tests further.
Cheers,
Peter Firmstone.
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
Jonathan Costers wrote:
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
