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 <n...@pivotal.io> 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 above over using @Rule. > > Regards > Nabarun Nag > > > On Nov 21, 2018, at 10:36 AM, Robert Houghton <rhough...@pivotal.io> > wrote: > > > > Great find, Patrick. I hope this shakes out some of the test bugs! > > > > On Wed, Nov 21, 2018, 10:34 Patrick Rhomberg <prhomb...@apache.org > wrote: > > > >> 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 and after each test. > >> > >> Problematically, JUnit rules applied in an unpredictable / JVM-dependent > >> ordering. [2] As a result, some flakiness we find in our tests may be > the > >> result of unexpected interaction and ordering of our test rules. [3] > >> > >> Fortunately, a solution to this problem already exists. Rule ordering > can > >> be imposed by JUnit's RuleChain. [4] > >> > >> In early exploration with this rule, some tests failed due to the > RuleChain > >> not being serializable. However, as it should only apply to the test > VM, > >> and given that it can be composed of (unannotated) rules that remain > >> accessible and serializable, it should be a simple matter of declaring > the > >> offending field transient, as it will only be necessary in the test VM. > >> > >> So, you dear reader: while you're out there making Geode the best it can > >> be, if you find yourself in a test class that uses more than one rule > >> listed in [1], or if you notice some other rule not listed below that > >> reaches out to VMs as part of its @Before or @After, please update that > >> test to use the RuleChain to apply the rules in a predictable order. > >> > >> Imagination is Change. > >> ~Patrick > >> > >> [1] A probably-incomplete list of invasive rules can be found via > >> $> git grep -il inEveryVM | grep Rule.java > >> > >> > geode-core/src/distributedTest/java/org/apache/geode/management/ManagementTestRule.java > >> > geode-dunit/src/main/java/org/apache/geode/test/dunit/rules/CacheRule.java > >> > >> > geode-dunit/src/main/java/org/apache/geode/test/dunit/rules/ClientCacheRule.java > >> > >> > geode-dunit/src/main/java/org/apache/geode/test/dunit/rules/DistributedDiskDirRule.java > >> > >> > geode-dunit/src/main/java/org/apache/geode/test/dunit/rules/DistributedRule.java > >> > >> > geode-dunit/src/main/java/org/apache/geode/test/dunit/rules/DistributedUseJacksonForJsonPathRule.java > >> > >> > geode-dunit/src/main/java/org/apache/geode/test/dunit/rules/SharedCountersRule.java > >> > >> [2] See the documentation for rules here: > >> https://junit.org/junit4/javadoc/4.12/org/junit/Rule.html ; notably, > >> "However, > >> if there are multiple [Rule] fields (or methods) they will be applied > in an > >> order that depends on your JVM's implementation of the reflection API, > >> which is undefined, in general." > >> > >> [3] For what it's worth, this was discovered after looking into why the > >> DistributedRule check fo suspicious strings caused the test *after* the > >> test that emitted the strings to fail. It's only tangentially related, > but > >> got me looking into when and how the @After was getting applied. > >> > >> [4] > https://junit.org/junit4/javadoc/4.12/org/junit/rules/RuleChain.html > >> > >
