geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Murmann <amurm...@pivotal.io>
Subject Slow DUnit tests for rolling upgrades
Date Wed, 18 Jul 2018 23:20:36 GMT
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.*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message