Hacker News Reader

Comment by BerislavLopac | Hacker News Reader

This example doesn't test for absence of any other elements, so it's not as precise.

That said, I largely agree with you - checking for this exact example from the README file works much better (and IMO more readable) as:

    assert set(result) == {"a", "b"}

The precisely example doesn't even check if the result is a list, so it can be anything.

View on HN

That is better, but doesn't check for incorrectly repeated elements:

    result = ["a", "b", "b"]
    assert set(result) == {"a", "b"}

In fact that is the first main motivating failure case discussed in the readme. But actually that's simple enough to deal with too:

    from collections import Counter
    assert Counter(result) = {"a": 1, "b": 1}

But would be trickier for mutable / unhashable types (not sure if "precisely" can deal with those).

Yup, precisely should work fine with mutable / unhashable types -- it just relies on equality to check the elements in an iterable.

More specifically, writing:

    contains_exactly("a", "b")

is equivalent to:

    contains_exactly(equal_to("a"), equal_to("b"))

Thanks for pointing out my brain fart :)

If the author of the library is reading, I think it would be a great addition to have a section discussing the benefit vs writing your own one line checkers.

One of the biggest benefits of libraries like this is that they tend to explicitly state the test author's intent.

To take your example from up top: If I'm coming to the code later, and I notice that it's not asserting for the absence of anything, it may be very difficult for me to tell whether that behavior is your intent, or just a brain fart.

It's just another layer of confusion in the many layers of confusion that lead to test rot.

To avoid repetitions, can you do this?

    assert sorted(result) == sorted(['a','b'])

I think that only works if `result` is a list

Nah, sorted can be used on any iterable

Ah that's better than my collections.Counter trick. Yours only needs the items to comparible rather than hashable, which is usually a looser requirement. (In principle you could have an object that's hashable but not comparible I can't immediately think of any).

The main problem is probably heterogenous collections. If you have a collection with both ints and strings then hashing will work fine but comparing will fail (in Python 3).

(Frozensets are hashable but not sortable but that's probably more niche.)

Or even better (since we're testing against an oracle value anyway):

    assert sorted(result) == ['a', 'b']

True you can just sort your oracle values once/in your head this is a valid point. Reasonable to prefer this way!

Reply on news.ycombinator.com