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