Is using pytruth considered Pythonic?

Question

I recently found Googles pytruth package. I am very used to pytest and I am wondering what the value of the way less commonly used pytruth is. The only reason why I didn't directly discard it, is that it comes from Google.

From the README, it seems to be mainly (only?) that you have the following ways to write assertions:

AssertThat(a).IsEqualTo(b)  # 1
AssertThat(c).IsTrue()  # 2
AssertThat(d).Contains(a)  # 3
AssertThat(d).ContainsAllOf(a, b)  # 4
AssertThat(d).ContainsAnyOf(a, b, c)  # 5
with AssertThat(Error).IsRaised():  # 6
  Explode()
AssertThat(result).ContainsExactlyElementsIn(expected)  # 7

I am used to write the following:

assert a == b  # 1
assert c  # 2
assert a in d  # 3
for element in [a, b]:  # 4
    assert element in d
assert any(element in d for element in [a, b, c])  # 5
with pytest.raises(Exception):  # 6
    Explode()
assert set(result) == set(expected)  # 7

Is there any difference between what I was doing and the truth package? Is there any reason to use the truth package? Is it maybe even considered good style?

Answer 1

Which way you find more readable, the pytruth ot the pytest way propably comes down to what you are used to. If you are used ot Java, you will find that more readable.

It is shared with the community to bring an expressive, consistent assertion style to projects that may be using a combination of unittest, abseil, googletest, mox, and mock—especially to people familiar with Java Truth.

(quoted from the pypilink)

JavaTruth, there we have it. So then, if you have to maintain Java and Python applications, this may be worth it to you for improved consistency.

As far as I see it, pytruth can be used with any testing framework. If you use pytest, you are locked in the whole framework. So if you want something different than pytest, you can use pytruth on top. If you are already bought into pytest, I'd personally rather prefer the way pytest handles asserts

Answer 2

Some of these, particularly 4, 5 and 7 are "clearly" more readable in the fluent truth style - the assertion does exactly what it does, no brainpower required.

It is also worth noting that your #7 does not match the truth example: think about what happens if d contains an element foo. Sure, you can fix it, but if you got it wrong writing the question, would you get it wrong writing production code as well?

Answer 3

According to the documentation, PyTruth claims to have more informative failure messages than some other widely-used testing frameworks in Python. (This is of course a subjective measure.)

Failure messages are very important in unit testing, and even more so in Test-Driven Development, where the failure message actually partially drives the implementation. ("Do the simplest thing that could change the failure message.")