Open dzirbel opened 2 years ago
I also wish these methods supported element-wise matching. I work a lot with lists and arrays of floating point numbers, and we're always told not to use exact equality matching for floating point numbers.
AssertJ for example has satisfiesExactly
where you pass a list of conditions for each element.
I find it very useful to use assertions like
containsExactly()
by providing aList
whose elements should match rather than vararg list of elements. This can be particularly helpful for more complicated tests that construct their reference elements rather than having them pre-defined.Moreover, I've found the API of
containsExactly()
to be somewhat error prone, in particular since it is defined onList<*>
with elements asAny?
it is possible to make assertions which make no "type-sense", for exampleI think (but may not have considered all the edge cases where parameterization might be ambiguous) that it would be possible to redefine this family of methods along the line of
This was particularly difficult when trying to override
containsExactly
with an extension method to solve the first problem; namely something likesince the
vararg Any?
parameters of the default method also match this signature.So, I have two questions:
contains*()
methods more typesafe by parameterization? If it's not possible for parametrization to cover all cases, perhaps we could consider a typesafe variant and one matching the current signature, or something along those lines.contains*()
variants with the input as aList/Iterable
? My implementation matches the naming pattern used by Google Truth, namely addingElementsOf
to these variants to disambiguate them, but there are a number of ways to do it.