Thinking about tests: assertions and matchers

This is one of the few irrational positions of mine, but I personally don't believe in matchers, with a passion :-)

For one off tests a plain assert without any messages works fine. For test suites, where investing in the quality of asserts pays off, I strongly believe in snapshot testing. Don't devise a fancy matcher. Instead, invest in the textual representation of the data, and then use the boring text diff to diff that. Fluent assertions occupy the in-between position, where they add more friction than a plain assert, but are less useful than full-blown snapshot tests. Maybe there's a class of tests where that is the optimum, but, even then, I'd rather stick to 2, rather than 3 tools.

I do appreciate pytest just making plain assert smarter.

I like this. I really like this. I'm going to start looking into implementing more custom matchers to match my systems' domains a bit better as a step forward with this. And for testing a singular class this is often enough.

But the problem I find myself running into in tests that confirm total system behavior starting from the API boundary of the whole system ("do we make the appropriate third party calls?" "do we write the correct objects to the DB?" etc.) is that the setup can get real big. I prefer not to rely on let or before because this often results in difficult-to-follow cascading setup in larger test files (bedeviling the ability to understand what all was used to set up the test), and I find myself leaning towards more factories with default behavior.

What are your thoughts on solving for large test setup?