InDeltaSlice doesn't check all expected values present

[philippslang]

For example

assert.InDeltaSlice(t, []float64{1, 2}, []float64{1}, 0.001)

passes because all elements of actual have a successful match in expected, but the opposite is not tested. Is this intentional?

[st3penta]

I think this is intentional, because the implementation here only iterates the length of actual.

Asserting that also all the elements of expected have a successful match in actual would basically mean to assert that the two slices have the same length.

Including this additional assertion would make the logic of InDeltaSlice more strict, thus risking to break existing tests that depend on it, that's why i think that at this point it is not a good idea to change it.

[brackendawson]

InDeltaSlice

InDeltaSlice is the same as InDelta, except it compares two slices.

InDelta

InDelta asserts that the two numerals are within delta of each other.

The docs aren't especially helpful in deciding if this is a bug or the documented behaviour. Unlike ElementsMatch it also only works on slices. But it does have slice in the name, which is also nice and inconsistent.

This issue could be resolved as a bug in v1 if you consider "compares two slices" to mean that it compares the two slices to one another.

Otherwise I'd propose for this function to be replaced in v2 with something more in line with the rest of the package's API, perhaps:

// ElementsInDetla asserts that the values of the elements in actual (array,
// slice, map...) are within the delta of the values of the elements in expected
// (array, slice, map...), irrespective of type.
ElementsInDelta(t TestingT, expected, actual any, delta float64)

We could possibly add that in v1 and deprecate InDeltaSlice.