Hi all, We just had a conversation among some members of the community about the increasingly slow DUnit tests that are related to rolling upgrades.
Please chime in with questions and concerns! Here are my notes from the discussion: *Why are rolling upgrade tests slow?Six versions of servers have to to be 1. Started with old version2. Do some work3. Shut down4. Updated5. Restarted6. Do more work and make assertionsThe above happens for every test method individually. This takes ~1 minute per method and per version. This is done serially right now for all methods within a class.Our other DUnit tests can reuse JVMs. These tests are starting a fresh JVM.How can we make them faster?Option 1: Move every test method into its own class. This will allow us to run them in parallelThis would allow us to run ~45 tests in parallelMight increase ease of exploring test suite.Option 2: Move rolling upgrade tests into their own Concourse job.This can be done in addition to other options.Option 3: Restricting what version jumps are supported.Can we decide to not support certain version jumps?Will we support jumping from Geode 1.x to arbitrary Geode 2.x version?Option 4: Change test runner to run for different version transitions in parallel.We could generate classes that contain the desired source and destination versions and then runs those in parallel.Next ActionsOptions 1 & 2 seem to be fairly simple changes without much downside and should get us far. Implementing those two solutions and seeing how long that leaves our test suite seem like the best first step. Jacob Barrett will take the lead on turning these two options into action.*
