pytest migration for unit.common.lenient.test__Lenient

[bjlittle]

🚀 Pull Request

Description

---

Consult Iris pull request check list

---

Add any of the below labels to trigger actions on this PR:

• benchmark_this Request that this pull request be benchmarked to check if it introduces performance shifts

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.74%. Comparing base (5000fd3) to head (f34f24c).
Report is 14 commits behind head on FEATURE_pytest_conversion.

Additional details and impacted files

@@                      Coverage Diff                      @@
##           FEATURE_pytest_conversion    #5828      +/-   ##
=============================================================
- Coverage                      89.74%   89.74%   -0.01%     
=============================================================
  Files                             92       92              
  Lines                          22942    22940       -2     
  Branches                        5464     5462       -2     
=============================================================
- Hits                           20590    20588       -2     
  Misses                          1620     1620              
  Partials                         732      732              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pp-mo]

IIUC,
assert bool(x) is True / assert bool(x) is False
are completely equivalent to
assert x / assert not x.

So... I'm thinking those would actually be simpler + easier to read.
But I guess you disagree !?!

[pp-mo]

Possibly a bit of a rant going here, but here's my thinking ..

I believe that "truthiness" in python is just always whatever "bool(x)" returns, and what the "if" and "assert" statements consider true or false is precisely "whatever bool says".
So you shouldn't write "if bool(x)" or "assert bool(x)" because that is already a guaranteed part of what "if" and "assert" are defined to do.
And if "if bool(x)" is redundant, because that's exactly what "if" does already, then also "if bool(x) is True" is doubly redundant, because that's exactly what "bool" does.
As far as I understand it, you can never have an x which passes "x ^ bool(x)", or "bool(x) & bool(x) is not True" or "not bool(x) & bool(x) is not False". Because "bool" is the only decider of "truthiness" in Python, and it only ever returns True or False.

And I think that whatever goes for "if" here goes for "assert" just as well.
I looked up "assert" in the Python docs, and they do state that it is equivalent to "if not x: raise"

[pp-mo]

assertEqual translations gone wrong here ...

Suggested change

	assert context["active"], expected["active"]
	assert set(context["client"]), set(expected["client"])
	assert post, self.default
	assert context["active"] == expected["active"]
	assert set(context["client"]) == set(expected["client"])
	assert post == self.default

[pp-mo]

Even if the bool(lenient[x]) is False/True style has value in asserting the behaviour of lenient[x] treated as a boolean,
I really don't think it has value here, because we already totally know that isinstance always returns a bool.
So,

Suggested change

	assert bool(isinstance(lenient.__dict__[service], Iterable)) is False
	assert not isinstance(lenient.__dict__[service], Iterable)

[pp-mo]

NB there are a few more of these ones, too

[pp-mo]

Cool, that is a big one !