Mapping support

[jayvdb]

unittest.TestCase.assertCountEqual supported mappings.

This is especially useful for comparing two json objects. It can be implemented by first checking the keys of both are 'unsorted equal', and then deeply checking each of the keys values.

[utapyngo]

Hi @jayvdb! Do you mean the output when an assertion fails?

[jayvdb]

No. I mean this TypeError is preventing usage on Mappings where they were supported by unittest
https://github.com/utapyngo/pytest-unordered/blob/761e1dd/pytest_unordered.py#L16-L19

[utapyngo]

assertCountEqual does not check the values of mappings. The following assertion does not fail:

first = {'x': 1, 'y': 2}
second = {'x': 2, 'y': 1}
TestCase().assertCountEqual(first, second)

With pytest-unordered, you can achieve the same with the following code:

assert first.keys() == unordered(second.keys())

This code just serves the purpose of making pytest-unordered more explicit.

pytest-unordered never makes recursive checks just for the same reason. Do you want unordered() to be applied implicitly to each of the values? What if some of them are also mappings? What if some of them are strings?

[jayvdb]

Right. That is a common misconception on what should happen with mappings. c.f. https://bugs.python.org/issue40909

If you want to force people to use the more explicit .keys(), perhaps the TypeError should suggest that.

Alternatively, pytest-unordered could do what unittest should do and check the .keys first and then then check the .values. Ideally recursively. (which appears to be wontfix for unittest: https://bugs.python.org/issue36201)

[utapyngo]

@jayvdb could you please provide a real-world example where recursive behaviour is required?

[rpocase]

@jayvdb could you please provide a real-world example where recursive behaviour is required?

I have a structure that looks like:

{
  "1": ["1", "2"]
  "2": ["3", "4"]
}

During test execution I compare against a similar structure, but I don't care about the order of values. This results in a test like:

for k, v in expected.items():
    assert k in actual
    assert v == unordered(actual[k])

This is certainly much cleaner than the alternative, but it would be nice to have a call that handles that for you. I could imagine a deeper nested structure that needs further recursive handling.

[utapyngo]

@rpocase: I would just use the following code instead:

expected = {
  "1": unordered("1", "2"),
  "2": unordered("3", "4"),
}
assert actual == expected

[rpocase]

@utapyngo That's definitely a lot better than my example. The only other use case I can think of is just a convenience. E.g., building assertions based on recording live results could save some minor data set clean up when integrating the results.

Implicit conversions could also be unsafe/unexpected, making interface extensions a must. Overall, I'm fairly convinced this likely isn't worth the effort without a much broader example.

[utapyngo]

It is usually better to explicitly mark unordered collections after recording live results.
If such "convenient" interface existed, everyone would use it where it is not needed.
I don't want to make a tool that lets you shoot yourself in the foot.