DUnit tests are junit tests that extend CacheTestCase or DistributedTestCase and run code in more than one VM. Because these tests tend involve multiple members in a distributed system, these tests are more prone to potential race conditions. Here are some tips for tracking down failures and fixing these tests.

Running a single test

You can use the standard gradle properties to run a single test. Or, better yet, run the test in your IDE to help you debug it.

Running a test multiple times

One way to run a test a lot of times is to add a new method to your case test that runs a problematic method many times. Here's an example

  public void testLoop() throws Exception {
    for(int i=0; i < 200; i++) {
      testGetBucketOwners();
      tearDown();
      setUp();
    }
  }

Running a list of tests

To save time, the JVMs are reused between test cases. This can cause issues if previous tests leave the JVM in a bad state. You can see the list of previously executed tests as the first step in the stdout of a test, if you are looking at a failure from jenkins:

Previously run tests: [PartitionedRegionHAFailureAndRecoveryDUnitTest, NetSearchMessagingDUnitTest, EvictionObjectSizerDUnitTest, PartitionedRegionBucketCreationDistributionDUnitTest, InterruptsConserveSocketsFalseDUnitTest, PartitionedRegionRedundancyZoneDUnitTest, DeltaFaultInDUnitTest, PutAllGlobalDUnitTest, DeltaPropagationStatsDUnitTest, P2PDeltaPropagationDUnitTest, PartitionedRegionPRIDDUnitTest, TransactionsWithDeltaDUnitTest, Bug33726DUnitTest, PartitionedRegionTestUtilsDUnitTest]

To run the same tests in order, you can add a suite to your junit test

public static Test suite() {
    Class[] classes = new Class[] {PartitionedRegionBucketCreationDistributionDUnitTest.class, InterruptsConserveSocketsFalseDUnitTest.class, PartitionedRegionRedundancyZoneDUnitTest.class, PartitionedRegionTestUtilsDUnitTest.class};
    return new TestSuite(classes);
  }

Fixing suspect strings

Distributed tests check the log output from each test for "suspect strings" which include any warnings, errors, or exceptions. If your test is supposed to log one of these strings, you can add an expected exception to the beginning of your test method, or even in your setUp method if all test cases are expected to log this message. There is no need to remove the expected exception, it is automatically removed in tearDown().

  public void testClientPutWithInterrupt() throws Throwable {
    addExpectedException("InterruptedException");
   //...
  }