I would say that the DistributedTestSuite is ripe for refactor - it grew pretty organically and hasn't had a good refactoring yet. ;)
What you suggested sounds reasonable - look forward to seeing the code. On Thu, Sep 29, 2016 at 4:48 AM, Tim Ellison <[email protected]> wrote: > On 29/09/16 01:50, Darin Johnson wrote: > > Hey guys, started working on refactoring into submodules and noticed a > few > > things. > > > > First the class DistributedTestSuite in org.apache.pirk.tests package is > > directly calling SparkLauncher, which can be avoided using platform > > (already a TODO). This will be needed to break the spark responder out. > No > > issues here' expected it. > > > > Also noticed that DistributedTestSuite calls > BaseTests.testDNSHostnameQuery > > which in turn calls the static method performQuery in > > DistTestSuite.performQuery so we've got a cyclic dependency. I'm > thinking > > this should be refactored, which shouldn't be hard - most of the method > are > > static. > > > > I figured I should solicit some thoughts on the best approach to going > > about this before jumping in. Comments welcome, especially as I haven't > > written anything yet :). > > > > My initial thoughts are the DistTestSuite should see what distributed > > frameworks are available (via plugin) and then run those tests. This > will > > likely require a setup helper for each framework though - the > DistTestSuite > > might then need to skip frameworks where the setup helper isn't found. > If > > this seems to be the approach people would like I'll start stubbing it > out > > and get some opinions. > > Yep, sounds reasonable. The distributed tests should discover what > platforms are available and run on them, perhaps printing a warning if > an expected project platform is not found. > > Looking forward to seeing the code. > > Regards, > Tim > >
