...

It's not absolutely necessary to introduce a new *RegressionTest class for covering a bug. If new regression test coverage fits better within an existing test class, then add one or more new tests to that existing test class but include javadocs on the new test methods which includes the GEODE JIRA ticket number and its summary at a minimum.

Testing Frameworks and Libraries Appropriate for Geode UnitTests

Overall Framework

• JUnit 4 (including Rules)
• Paramerized – JUnit 4.12 has a bug which prevents Parameterized and Category from working together properly
  • Please use CategoryWithParameterizedRunnerFactory from Geode when using Parameterized (see GEODE-1350)

Assertion Library

• AssertJ – richer API with better failure messages than JUnit 4 Assert

Mocking Library

• Mockito
• PowerMock – use this as a last resort – refactoring code to facilitate better testing is preferred

Expected Exceptions

• Use AssertJ or Catch-Exception instead of JUnit 4 Rule ExpectedException
• AssertJ (assertThatThrownBy) – this is the cleanest and preferred way to test for expected exception
• Catch-Exception – better support for complex nesting of exceptions or exceptions with unusual APIs

Additional 3rd Party Libraries for UnitTests

• JUnitParams – provides test method parameterization (usually better to use than JUnit 4 Parameterized)
• System Rules – powerful set of JUnit 4 Rules
• Awaitility* – useful for awaiting asynchronous conditions

(*=Concurrency frameworks or rules are typically more appropriate for IntegrationTests)

Custom Geode JUnit 4 Rules and Testing Tools

• RestoreLocaleRule – restores JVM to original Locale
• RestoreTCCLRule – restores Thread Context Class Loader
• ExecutorServiceRule* – provides ExecutorService for concurrent testing

(*=Concurrency frameworks or rules are typically more appropriate for IntegrationTests)

Examples of actual tests

Examples of some good UnitTests:

...