Show HN: Mintaka: Run long-running processes, automatically focus on problems
github.com2 pointsby mwilliamson0 comments
contains_exactly("a", "b")
is equivalent to: contains_exactly(equal_to("a"), equal_to("b")) assert_that(result, contains_exactly("a", "b"))
I'd suggest that the above states the intention of the assertion, rather than how you check it. For instance, your assertion would allow duplicate elements, whereas the assertion as originally written would suggest that this isn't desired. As other comments have pointed out, you can do things with sorted, Counter or set (depending on exactly what you want to assert), but why worry about what trick to use when you could just directly state your intention? assert_that(result, contains_exactly(
has_attr(name="Alice"),
has_attr(name="Bob"),
))
How would you write something that means the same thing without precisely? The order isn't deterministic, so you can't write something like: assert result[0].name == "Alice"
assert result[1].name == "Bob
assert len(result) == 2
We could sort the users by name before making the assertion: result = sorted(result, key=lambda user: user.name)
assert result[0].name == "Alice"
assert result[1].name == "Bob
assert len(result) == 2
Personally, I prefer the precisely assertion! assert set(result) == {
User(id=1, name="Alice", email_address="[email protected]"),
User(id=2, name="Bob, email_address="[email protected]"),
}
Now we've over-specified our test -- we need to know irrelevant details like the ID and e-mail address of the users, which might change and break this test even when the functionality we care about still works. We'll also break the test if we add any more attributes to users.