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.ti...@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 >> <peter.firmst...@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 >> >