Refactor integration tests to support multiple C* distributions #1958
Conversation
… with DataStax HCD 1.0.0
| @@ -61,7 +62,7 @@ public class CcmBridge implements AutoCloseable { | |||
|
|
|||
| public static final String BRANCH = System.getProperty("ccm.branch"); | |||
|
|
|||
| public static final Boolean DSE_ENABLEMENT = Boolean.getBoolean("ccm.dse"); | |||
| public static BackendType distribution = null; | |||
There was a problem hiding this comment.
Semi-nit: this should be DISTRIBUTION to be consistent with the other static variables in this class. I don't normally get too excited about style things like this but in this case we use all cap for static var names so that they can easily be identified when trawling through code.
| if (Boolean.parseBoolean(System.getProperty(enableFlag, "false"))) { | ||
| distribution = backendType; | ||
| break; | ||
| } |
There was a problem hiding this comment.
At this point I'm starting to wonder if it isn't just easier to support a single env var whereby you can specify the backend you want.
ccm.backend=dse
ccm.backend=hcd
etc.
There was a problem hiding this comment.
Totally agreed. I wanted to preserve backward compatibility of flags, but true this makes far more sense.
| dse.put(Version.V5_0_0, CcmBridge.V3_0_15); | ||
| dse.put(CcmBridge.V5_1_0, CcmBridge.V3_10); | ||
| dse.put(CcmBridge.V6_0_0, CcmBridge.V4_0_0); | ||
| mappings.put(BackendType.DSE, dse); |
There was a problem hiding this comment.
Nit: Guava's ImmutableMap builder make this a bit cleaner:
Map<Version, Version> dse = ImmutableMap.of(Version.V1_0_0, CcmBridge.V2_1_19, Version.V5_0_0, CcmBridge.V3_0_15,...)
There was a problem hiding this comment.
It needed to be TreeMap, so changed to ImmutableSortedMap.
| @@ -598,7 +598,7 @@ public void should_allow_use_of_dsl_graph_binary() throws Exception { | |||
| @Test | |||
| public void should_return_correct_results_when_bulked() { | |||
| Assumptions.assumeThat( | |||
| ccmRule().getCcmBridge().getDseVersion().get().compareTo(Version.parse("5.1.2")) > 0) | |||
| ccmRule().getCcmBridge().getDistributionVersion().compareTo(Version.parse("5.1.2")) > 0) | |||
There was a problem hiding this comment.
This seems like a change in logic. Before we were getting the DSE version specifically and comparing it to the min version we want to support for this test. Here we're getting a "distribution version" (which could be anything) and checking to see if it exceeds the min version. We should somehow be validating that we're dealing with a DSE version when we get it.
Note that GraphTraversalRemoteITBase above does exactly the same check... but it makes sure we're dealing with a DSE distribution before we continue on.
There was a problem hiding this comment.
Thank you for catching this. I do not know how I overlooked it. Fixed.
| Assumptions.assumeThat( | ||
| dseVersion.isPresent() && dseVersion.get().compareTo(Version.parse("5.1.2")) > 0) | ||
| CcmBridge.isDistributionOf(BackendType.DSE) | ||
| && CcmBridge.getDistributionVersion().compareTo(Version.parse("5.1.2")) > 0) |
There was a problem hiding this comment.
This feels like we're just moving the problem around a bit. We haven't decreased the verbosity... we've just moved it around a bit.
There are a lot of instances of things that use this pattern:
Are we DSE/OSS/HCD && are we greater than/less than/something else some specific version
The removal of the Optional types here (i.e. the removal of CcmBridge.getDseVersion() below) means that we have to remember to do both of the checks above manually. If we were to make better use of the Optional type, however, we could do the whole thing in a single check. For example, the statements above can also be expressed as:
Assumptions.assumeThat(
ccmRule().getCcmBridge().getDseVersion().map(v -> v.compareTo(Version.parse("5.1.2")) > 0).orElse(false))
.isTrue();
In this case if getDseVersion() returns an empty Optional (because we aren't dealing with DSE) the orElse() will return false. Otherwise we do the integer compare and return true or false based on it's results. This approach allows us to encapsulate all the checks we want into a single line of logic. I'd argue that's more desirable in a test framework like this where you want to make sure your base assumptions are respected before moving on to the actual tests.
Refactored integration tests to be able to support multiple C* distributions (not only DSE vs. OSS).