Improved keys assertions in ObservationContextAssert #3266
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The first part of this change adds two assertions around keys
(considering both low cardinality and high cardinality KeyValues).
It is currently possible to individually assert specific keys are
present, either focusing on the key itself being there or specifying the
expected key and value pair.
For example
hasLowCardinalityKeyValueWithKey("k")
orhasHighCardinalityKeyValue("k", "v")
). But it isn't possible toquickly also make sure that no other keys are present outside of the
ones asserted via these methods.
Let's imagine my
actual
has 3 keys "A", "B" and "C" but I only expect"A" and "B": without having prior knowledge of "C", its absence cannot
be asserted.
Adding
hasKeyValuesCount
is a good complement for this: in the examplehaving
hasKeyValuesCount(2)
would fail with a message indicating 3keys are present instead of 2.
Adding
hasOnlyKeys
could also serve the same purpose if the onlyconcern is having the keys, whatever the values are. As such
hasOnlyKeys("A", "B")
in the example would fail with a message sayingthat extraneous key "C" was found.
hasOnlyKeys("A", "B", "C", "D")
would also fail with a message stating that key "D" is missing.
The second part of this change fixes a counterintuitive behaviour of the
doesNotHave[High|Low]LevelKeyValue(String, String)
assertions: if thekey is present with another value than the one specified, the assertion
currently fails by complaining the key is present.
But if both a key and a value are specified then only that specific
pair should be undesirable. So for that same key we should accept values
that do not match the one specified. (for a similar example in AssertJ
core, see
Map
'scontainsEntry
assertion).