Dealing with fixtures is one of the areas where pytest really shines.
This is rather an incredible understatement.

The xunit style of test fixtures that is used in both unittest and nose is of course supported with with pytest. And pytest rocks at this.

But there is another way to deal with fixtures. It’s to think of fixtures as a set of resources that need to be set up before a test starts, and cleaned up after. Test functions, methods, classes, name wich fixtures they need. This way, fixtures aren’t set up for tests that don’t need them.

This focus on the fixture as a modular resource, possibly set up once for many tests, or perhaps for each test, is a really cool way to treat fixtures.
However, it took me a while to really get my head around it.

I’ve been thinking about it for months, and have started many, many attempts at a ‘pytest fixture’ post.

Truth. I don’t think one post will do it justice.
So, I’ll take a bit at a time, and try to cover it in a way that I can express how cool I think pytest fixtures are, and hopefly completely enough that you can use them effectively.

It’s not complicated to use. It’s really quite simple.
But it’s different enough from what I was used to that I think a series of posts would be best.

Some of these bullets below will be their own post, and some posts will cover multiple bullets. And I’m sure I’ll think of more to say as I start writing.
However, I’ll come back and fill in these bullets as links, so bookmark this post.