> I don't understand the mentality of posts like this.

The purpose is simply to put my opinions and experience into writing. I chose to share in case it is useful to others, which it turned out to be. The intention is also to inspire teams to formalize their own list like this, and to establish a culture around how to write tests.

> I don't think it's true, but if it's true, make an argument.

That wasn't my purpose of this post. Every listed item in the article is a choice, for each of those there are alternatives with trade-offs.

> I don't think you know what a good test is.

Likewise, from what you describe as a "powerful" test sounds to me like nightmare to maintain and it saddens me to think about what you have left behind for posterity over the course of 30 years. I don't think tests should be powerful, I think they should be dumb and dead-simple to understand, and that they rather build usefulness in numbers.

While I agree with you on all your remaining points, one could argue that logic in tests has a non-zero risk of being flawed or buggy on its own. Worst case, a bug in the test's logic and another in the logic under test cancels each other out.

That's why I've made it a habit to write only strictly linear tests in my own code, and use fixtures and parametrization to keep duplication to a minimum.

Ultimately, there's no one true best strategy. Everything is full of trade-offs all the way down.

Since I actively supervise my testing, and actively test my tests, I don’t find the prospect of mistakes in my test code to be terrifying.

I don’t understand why the possibility of difficulty with test code should cause me to write shallow, lame test code.