Add support for assertCountEqual

[verhovsky]

#46

[verhovsky]

The docs for assertCountEqual say

Equivalent to: assertEqual(Counter(list(first)), Counter(list(second))) but works with sequences of unhashable objects as well

New in version 3.2.

So rewriting it as Counter(first) == Counter(second) isn't an entirely correct conversion. But I thought omitting the conversion to a list is cleaner. Counters work on generators and couldn't think of another reason for why you'd want to convert the iterables to a list. The "works with sequences of unhashable objects" part is a bigger deal, I don't know what do to about that.

[nicoddemus]

The "works with sequences of unhashable objects" part is a bigger deal, I don't know what do to about that.

Yes, the implementation has a fallback for that... we would need to provide something similar I guess.

[Code0x58]

The "works with sequences of unhashable objects" part is a bigger deal, I don't know what do to about that.

Yes, the implementation has a fallback for that... we would need to provide something similar I guess.

One approach given UnitTest.assertCountEqual(…) would be to map self.assertCountEqual(…) to:

unittest.TestCase().assertCountEqual(…) # simple and portable way to do it
unittest.TestCase.assertCountEqual(pytest, …) # `self` is `pytest` because it only uses `self.fail` so conveniently works but is hacky

It could be a bit hairy to work out how to address TestCase in the code without making more assumptions, but probably not too much concern to reuse TestCase because in most cases the module would still be available going forward - except if unittest was downgraded/removed e.g. for version conflicts.

I find I use unittest2pytest to refactor TestCase classes into pytest methods, so would be happy to see it mapped to unittest.TestCase().assertCountEqual(…) to make sure things done break.

That said, as a user I wouldn't mind the assert Counter(a) == Counter(b), msg approach along with documentation saying saying that it's a potential issue which could require manual intervention, which you can find out when you run your tests. Being able to opt-in/out-out of this transform (i.e. having it in a separate "fix") would be great for those who don't want to break their tests (although I'm not sure that guarantee currently exists in unittest2pytest). When using git you can choose which hunks to include and discard when using git add --interactive …, so would be easy enough to revert if you want in particular cases.

[dannysepler]

just comparing apples to oranges, i implemented this as assert sorted(a) == sorted(b)! which allows us to get around needing to import collections but on the other hand may fail if we're counting classes that aren't sortable 🤷