Page History

...

• Improve green consistency of distributed tests
• Mass test runs determined which tests we worked on
• Prioritized any tests that failed more than once in our mass test runs
• Fixed about 35 issues (working on more)
• Spent about a quarter of our time fixing product bugs
• Anecdotal improvements for Geode developers
• “CIO board is cleaner”
• “Seeing more Green pull requests”

Green Team Progress

If

I

had

a

nickel

for

every

thread

sleep

related

failure...

What was helpful vs unhelpful

...

Examples: SleepDistributedTest, MultiThreadedIntegrationTest

It’s not polite to eat all the exceptions...

Exception handling

• Expected vs unexpected exceptions in tests
• Never catch unexpected exceptions. That is bad... way bad...
• Special case: Asynchronous actions may need to catch checked exceptions and use ErrorCollector
• Use method throws clause for unexpected exceptions 
• The alternative serves to make failures more opaque. 
• Fixing test failures (as you will have to do at some point) is all about visibility into the problems of the test. 
• Use AssertJ catchThrowable or assertThatThrown for expected exceptions
• Avoid using JUnit expected exception support such as ExpectedException Rule or Test annotation expected element. Example: @Test(expected = Exception.class) 
• Remember to catch specific exceptions, not whole parent classes. If someone adds an additional exception, will it break your test?

Examples: ErrorHandlingTest, ExpectedExceptionTest

Sometimes you think they’re helping...

Minimize helper classes

• All test code should be in the test class
• Test should directly use Geode User APIs without helper classes
• Most Geode developers already know the Geode APIs or should learn them
• See how Geode is configured and what’s happening directly in the test code
• Easier to debug especially if product bugs are suspected
• Developers understand usability issues in the Geode User APIs
• Every layer between the test and what you are testing obscures the test and make debugging more difficult for you and everyone else
• Avoid generalizing classes such as CacheListeners for many tests
  • Use specialized inner classes that are specific to the tests in the test class
  • Flexibility and generalization are sources of complexity
  • Complexity is a source of bugs and difficult debugging
  • Complexity and generalization is a wall that prevents people from making educated changes
  • All code including configuration should be in the test class
  • Write your code for the next person to look at it.
• Helper classes cause problems
  • Obscure what’s happening
  • Proliferate bad anti-patterns
  • Combine test classes that should be separate

Challenges when handling things asynchronously...

Use ExecutorServiceRule for multithreading

...