Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-26 Thread Kirk Lund
Typo fix: If you need to use CleanupDUnitVMsRule along with other dunit rules, then you will need to* use RuleChain*. If you don't need to use CleanupDUnitVMsRule then you don't need to use RuleChain. On Mon, Nov 26, 2018 at 11:57 AM Kirk Lund wrote: > Actually the only problem with this is

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-26 Thread Kirk Lund
Actually the only problem with this is specific to bouncing of dunit VMs. I filed "GEODE-6033: DistributedTest rules should support VM bounce" earlier this month and I have a branch with preliminary changes that seem to be working fine. Aside from bouncing of dunit VMs, the dunit rules you listed

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-26 Thread Mark Hanson
Thanks for the correction Bruce! > On Nov 26, 2018, at 10:04 AM, Bruce Schuchardt wrote: > > While it's common to use VM.getVM(int) to get a VM you still must use > Host.getHost() to get a VM running an older version of Geode. Until someone > adds a VM.getVM(version, vmNumber) we can't frown

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-26 Thread Bruce Schuchardt
While it's common to use VM.getVM(int) to get a VM you still must use Host.getHost() to get a VM running an older version of Geode. Until someone adds a VM.getVM(version, vmNumber) we can't frown upon Host.getHost(0).getVM(startingVersion, 0). On 11/21/18 4:09 PM, Mark Hanson wrote: It is

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-26 Thread Helena Bales
Is there a preferred ordering of the above list of rules? Or is the preferred ordering whichever passes? On Wed, Nov 21, 2018 at 4:36 PM Mark Hanson wrote: > It is frowned upon. VM.getVM(0) is now the accepted way to get VM 0. > > Thanks, > Mark > > > > On Nov 21, 2018, at 10:41 AM, Nabarun

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-21 Thread Mark Hanson
It is frowned upon. VM.getVM(0) is now the accepted way to get VM 0. Thanks, Mark > On Nov 21, 2018, at 10:41 AM, Nabarun Nag wrote: > > Will doing this in the test, > > final Host host = Host.getHost(0); > VM server1 = host.getVM(startingVersion, 0); > > be frowned upon, if I use the

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-21 Thread Patrick Rhomberg
Within a test itself, reaching out to the host / VM that way should be fine, since you know that it will be executing after any rule's before() method. On Wed, Nov 21, 2018 at 10:49 AM Nabarun Nag wrote: > Will doing this in the test, > > final Host host = Host.getHost(0); > VM server1 =

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-21 Thread Nabarun Nag
Will doing this in the test, final Host host = Host.getHost(0); VM server1 = host.getVM(startingVersion, 0); be frowned upon, if I use the above over using @Rule. Regards Nabarun Nag > On Nov 21, 2018, at 10:36 AM, Robert Houghton wrote: > > Great find, Patrick. I hope this shakes out some

Re: Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-21 Thread Robert Houghton
Great find, Patrick. I hope this shakes out some of the test bugs! On Wed, Nov 21, 2018, 10:34 Patrick Rhomberg tl;dr: Use JUnit RuleChain. > > > Hello all! > > Several [1] of our test @Rule classes make use of the fact that our DUnit > VMs Host is statically accessible to affect every test

Avoiding Unpredictability in Our DUnit Testing Rules

2018-11-21 Thread Patrick Rhomberg
tl;dr: Use JUnit RuleChain. Hello all! Several [1] of our test @Rule classes make use of the fact that our DUnit VMs Host is statically accessible to affect every test VM. For instance, the SharedCountersRule initializes a counter in every VM, and the CleanupDUnitVMsRule bounces VMs before