Open PragTob opened 3 years ago
Funny enough, when I think of two lists as "equal," I always think of the contents and not the order, which is why I think this bug comes up so often in so many tests for folks. I (and I think many others) think of ==
as saying "Make sure these two lists have the same things in them," but what ==
really says is "Make sure these two lists have the same things in them, and make sure the lists are in the same order," so in my mind ==
is something more than "equal."
That said, I can totally see how this name might be confusing to many others, though, even though it makes sense to me, so I'm happy to explore a name change here. How about assert_lists_equivalent
? Looking at the definition for equivalent
I like this third one of corresponding or virtually identical especially in effect or function
, so that seems like a potentially good fit. My biggest issue there is that I can never remember how to spell it, but tab complete should make that not so much of a problem :wink:
Funny enough, when I think of two lists as "equal," I always think of the contents and not the order, which is why I think this bug comes up so often in so many tests for folks. I (and I think many others) think of
==
as saying "Make sure these two lists have the same things in them," but what==
really says is "Make sure these two lists have the same things in them, and make sure the lists are in the same order," so in my mind==
is something more than "equal."That said, I can totally see how this name might be confusing to many others, though, even though it makes sense to me, so I'm happy to explore a name change here. How about
assert_lists_equivalent
? Looking at the definition forequivalent
I like this third one ofcorresponding or virtually identical especially in effect or function
, so that seems like a potentially good fit. My biggest issue there is that I can never remember how to spell it, but tab complete should make that not so much of a problem 😉
I share the same thoughts as you @devonestes .
Giving my 2cents on the discussion you've raised, there is another possible solution for your naming where assert_lists_equal
could also accept an option to ensure the order. Like this
Assertions.assert_lists_equal(list_a, list_b, ensure_order: true)
This way you could keep the name as it is, and for devs it's cleaner what the default behaviour is
Would assert_lists_equal_unordered
be a viable option?
equal
implies full equality aka==
which seems confusing (and was pointed out as a downside to introducing assertions into our code base).Not sure what the best name for this is, I introduced a small wrapper called
assert_lists_contain_same
for now - it's probably not the best for now happy for other variants but I wonder ig this would be a change considered for the library itself?Wrapper for reference, yes it's just a module for now not a macro: