Rename :assert_lists_equal to :assert_order_indifferent_equal

[sitch]

Can be a little unclear what the actual comparison is here as we do have a strict equality operator.

A bit more verbose but more clear about intention would be something like assert_order_indifferent_equal

Which would work apply to any enumerable:

List

assert_order_indifferent_equal [:a, :b, :c], [:c, :a, :b]

Binaries

assert_order_indifferent_equal "abc", "cab"

Maps with nested ordered enums

assert_order_indifferent_equal %{a: [:a, :b, :c]}, %{a: [:c, :a, :b]}

[devonestes]

Howdy!

My thinking is that in many lists, the order doesn't really matter, but I can't really think of a string where order doesn't matter. All of these assertions came out of repeated use in many different projects in the real-world ,so that's why I don't really think that use case is going to be a good fit here.

For the maps with enums as keys, I'd write that assertion like so:

assert_maps_equal(%{a: [:a, :b, :c]}, %{a: [:c, :a, :b]}, fn left, right ->
  assert_lists_equal(left.a, right.a)
end)

or just

actual = %{a: [:a, :b, :c]}
expected = %{a: [:c, :a, :b]
assert_lists_equal(actual.a, expected.a)

All of these assertions are designed for composition, since maps can have any depth and any value, so you'll need to handle those specifically each time.

But I'm totally open to hearing some common things you need assertions for and other use cases if you have some to share!

[sitch]

Yeah my thoughts were more in the category theory sense of:

Setoid

Enumerable where ==/!= compares set elements

Ord

Setoid with ordered enumerables. So add > /< and have the ==/!= impose an additional ordering requirement

I would think the clearest technical assertions would defmacros that pin the operators above so you have:

iex> assert_setoid %{a: [:a, :b, :c]} == %{a: [:c, :b, :a]}
true

iex> assert_ord %{a: [:a, :b, :c]} == %{a: [:c, :b, :a]}
false

iex> assert_ord %{a: [:a, :b, :c]} < %{a: [:c, :b, :a]}
true