Re: Why jtreg

[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

[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
>> >