Write Good Python Tests
agest.am
agest.am
I've been a tester for more than thirty years, I have my own ideas about how I like to test. I put logic in my test code. This is because I want to write powerful tests that find fucking bugs.
It's not intuitively obvious that making more and different little checks is logically equivalent or superior to complex and interesting test code. I don't think it's true, but if it's true, make an argument. Don't just assert and moralize.
I don't think you know what a good test is.
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.
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.
I don’t understand why the possibility of difficulty with test code should cause me to write shallow, lame test code.