You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dennis Reedy <de...@gmail.com> on 2020/07/13 20:58:39 UTC
Why jtreg
As the title says, why use jtreg? We have modern test frameworks (Junit,
Spock, etc...). Asd we move forward with River, why not migrate tests to
use these?
Regards
Dennis Reedy
Re: Why jtreg
Posted by Dennis Reedy <de...@gmail.com>.
Hi Zsolt,
Create a pull request and I’ll merge it in
Thanks
Dennis
> On Aug 10, 2020, at 7:15 AM, Zsolt Kúti <la...@gmail.com> wrote:
>
>
> Hi guys,
>
> Based on the SVN and Dennis' git repos, I now have a local git repo that contains a gradlefied new test module. It accomplishes little for the time being:
> - follows River's gradle project format
> - rectified (removed unused imports, corrected some package definitions etc.) that prevented compiling
> - can now be compiled
>
> I planned to create at least one working Spock unit test to see how it works out, but unfortunately was overwhelmed with other duties.
> I thought that moving unit tests to their respective modules may come in a later phase, or as soon as a new test is created.
>
> Now, before leaving for long holidays it may be the time to merge this work to somewhere.
> Should I make my own github repo and put these changes there? I do not know how pull request on Dennis' would work with large number of files/changes (~ 5000).
>
> Ideas?
>
> Zsolt
>
>> On Tue, Jul 14, 2020 at 12:23 AM Peter Firmstone <pe...@zeus.net.au> wrote:
>> Why not indeed :)
>>
>> I'd be in favour of moving "unit tests" out of the jtreg and qa tests
>> suites into junit first . I'd suggesting leaving the jtreg bug
>> regression tests where they are for now at least, as far more work is
>> required and they may not all be relevant; we no longer have bug
>> descriptions or information on these bug's, as Oracle has removed them
>> from the Sun bug database. I have looked into the undocumented
>> regression tests previously, some are very difficult to figure out. I
>> have made some attempts at recovering information on older bugs for
>> these regression tests from release notes of earlier versions of Jini,
>> but haven't had much luck, requests for information from Oracle go
>> unanswered.
>>
>> The tests can be broken down into:
>>
>> 1. Unit tests - simple tests that don't need more than one running jvm,
>> eg a lookup service, or activation and don't require a
>> SecurityManager (maybe junit is ok with a security manager? Just
>> need appropriate policy files?).
>> 2. Integration tests - requires multiple jvm's, eg testing network
>> functionality (typically in the qa suite).
>> 3. Bug regression tests - testing a known, or often in our case, an
>> undocumented bug.
>>
>> River never received an upload of the Sun bug database relating to Jini,
>> Oracle has long since made it inaccessible. Many of the bug regression
>> tests in jtreg lack documentation, I guess there might be some
>> information in the Jini users mail list archives.
>>
>> I'd suggest grabbing the low hanging fruit first.
>>
>> Cheers,
>>
>> Peter.
>>
>> On 7/14/2020 6:58 AM, Dennis Reedy wrote:
>> > As the title says, why use jtreg? We have modern test frameworks (Junit,
>> > Spock, etc...). Asd we move forward with River, why not migrate tests to
>> > use these?
>> >
>> > Regards
>> >
>> > Dennis Reedy
>> >
Re: Why jtreg
Posted by Zsolt Kúti <la...@gmail.com>.
Hi guys,
Based on the SVN and Dennis' git repos, I now have a local git repo that
contains a gradlefied new test module. It accomplishes little for the
time being:
- follows River's gradle project format
- rectified (removed unused imports, corrected some package definitions
etc.) that prevented compiling
- can now be compiled
I planned to create at least one working Spock unit test to see how it
works out, but unfortunately was overwhelmed with other duties.
I thought that moving unit tests to their respective modules may come in a
later phase, or as soon as a new test is created.
Now, before leaving for long holidays it may be the time to merge this work
to somewhere.
Should I make my own github repo and put these changes there? I do not know
how pull request on Dennis' would work with large number of files/changes
(~ 5000).
Ideas?
Zsolt
On Tue, Jul 14, 2020 at 12:23 AM Peter Firmstone <
peter.firmstone@zeus.net.au> wrote:
> Why not indeed :)
>
> I'd be in favour of moving "unit tests" out of the jtreg and qa tests
> suites into junit first . I'd suggesting leaving the jtreg bug
> regression tests where they are for now at least, as far more work is
> required and they may not all be relevant; we no longer have bug
> descriptions or information on these bug's, as Oracle has removed them
> from the Sun bug database. I have looked into the undocumented
> regression tests previously, some are very difficult to figure out. I
> have made some attempts at recovering information on older bugs for
> these regression tests from release notes of earlier versions of Jini,
> but haven't had much luck, requests for information from Oracle go
> unanswered.
>
> The tests can be broken down into:
>
> 1. Unit tests - simple tests that don't need more than one running jvm,
> eg a lookup service, or activation and don't require a
> SecurityManager (maybe junit is ok with a security manager? Just
> need appropriate policy files?).
> 2. Integration tests - requires multiple jvm's, eg testing network
> functionality (typically in the qa suite).
> 3. Bug regression tests - testing a known, or often in our case, an
> undocumented bug.
>
> River never received an upload of the Sun bug database relating to Jini,
> Oracle has long since made it inaccessible. Many of the bug regression
> tests in jtreg lack documentation, I guess there might be some
> information in the Jini users mail list archives.
>
> I'd suggest grabbing the low hanging fruit first.
>
> Cheers,
>
> Peter.
>
> On 7/14/2020 6:58 AM, Dennis Reedy wrote:
> > As the title says, why use jtreg? We have modern test frameworks (Junit,
> > Spock, etc...). Asd we move forward with River, why not migrate tests to
> > use these?
> >
> > Regards
> >
> > Dennis Reedy
> >
>
Re: Why jtreg
Posted by Peter Firmstone <pe...@zeus.net.au>.
Why not indeed :)
I'd be in favour of moving "unit tests" out of the jtreg and qa tests
suites into junit first . I'd suggesting leaving the jtreg bug
regression tests where they are for now at least, as far more work is
required and they may not all be relevant; we no longer have bug
descriptions or information on these bug's, as Oracle has removed them
from the Sun bug database. I have looked into the undocumented
regression tests previously, some are very difficult to figure out. I
have made some attempts at recovering information on older bugs for
these regression tests from release notes of earlier versions of Jini,
but haven't had much luck, requests for information from Oracle go
unanswered.
The tests can be broken down into:
1. Unit tests - simple tests that don't need more than one running jvm,
eg a lookup service, or activation and don't require a
SecurityManager (maybe junit is ok with a security manager? Just
need appropriate policy files?).
2. Integration tests - requires multiple jvm's, eg testing network
functionality (typically in the qa suite).
3. Bug regression tests - testing a known, or often in our case, an
undocumented bug.
River never received an upload of the Sun bug database relating to Jini,
Oracle has long since made it inaccessible. Many of the bug regression
tests in jtreg lack documentation, I guess there might be some
information in the Jini users mail list archives.
I'd suggest grabbing the low hanging fruit first.
Cheers,
Peter.
On 7/14/2020 6:58 AM, Dennis Reedy wrote:
> As the title says, why use jtreg? We have modern test frameworks (Junit,
> Spock, etc...). Asd we move forward with River, why not migrate tests to
> use these?
>
> Regards
>
> Dennis Reedy
>