Thanks for the support! It means a lot, especially from someone who shares the pytest frustration.
About bare `assert`s. Vedro is actually flexible enough to use any matchers you prefer, but let me share why I stick with plain asserts:
1. In most editor themes, `assert` jumps out with distinct syntax highlighting. When scanning tests, I can quickly spot the assertions and understand what's being tested.
2. The expressions feel cleaner to me:
assert error_code not in [400, 500]
# vs
assert_that(error_code, is_not(any_of(400, 500))) # hamcrest
3. I like that there's nothing new to learn, the expressions work exactly like they do in any Python code, with no special test behavior or surprises.
Would love to hear what specifically bothers you about bare asserts, always looking to understand different perspectives on testing ergonomics!
Your first and second points makes sense. They don't matter much to me, but I see how others could value those things.
Aside: I also don't like the hamcrest syntax. I also don't love unittest's syntax but it's OK and it's pervasive (i.e., available in the stdlib).
The third point is where I start to disagree more strongly.
> I like that there's nothing new to learn, the expressions work exactly like they do in any Python code, with no special test behavior or surprises.
This doesn't seem true to me.
> the expressions work exactly like they do in any Python code
Not to my mind. In normal Python, an assertion communicates something that is unequivocally believed to be true, not something that may or may not be true (a test). Let me see if I can explain it this way, I often use asserts in tests to show (and enforce) something that I believe to be true and must be true, before the test can have any meaning. E.g.,
The "assert" communicates that this is a precondition, the "self.AssertTrue" communicates that this is a test.
I can 100% see that others might not see/care about the distinction, but I think it is important.
> no special test behavior
Well, that's not quite true. You have to handle the AssertionError specially and do some fairly magical work to figure out the details of the expression that failed. The unittest-style assertions just report the values passed into them.
I don't really like that magic, both from an aesthetic standpoint and from a least-complexity-in-my-tooling standpoint. Again, I can understand others making different tradeoffs.
I think the ambition is much larger than what could be accomplished by part-time volunteer work. It was either this or somehow get a bigcorp to dedicate 2, 5, 10 full time salaries to it.
Honestly it's not clear to me that the money they have in income now is enough to accomplish the ambition, but I guess that's why it is a fundraiser in addition to a financial report.
It seems like the standard around me is between 8 to 12 people. This is too many in my opinion.
I believe this is because management is unknowingly aiming for the biggest team the does not completely halts instead of seeking a team that delivers the most bang for the buck.
I don't know of a canonical XP team size, but "small" is the normal recommendation. 8-12 would seem larger than small to me.
Personally, 8 is the largest I would have a team. At that point you should consider breaking it into two teams of 4 (even if those teams periodically recombine from the original set of 8 people).
I find it non trivial to split a team in two independent teams.
If the two teams have to coordinate a lot and work on the same code base, is there still two teams?
To be independent, they would need to work on functionnaly different parts of the project. Not all projects have several independent parts, feature-wise.
reply