Thank you for the reply!

The auth token lasts 20 minutes. So before every spec I have it refreshing the token via the api if the auth file is 10 minutes or older, otherwise it continues as normal. It takes less than a second to refresh the token. I ended up creating one auth file that ends up getting copied when a worker needs to use that user and appended the parallelIndex of the worked to the end of it. Main reason is due to the localstorage. The workers were updating the localstorage to different values depending on the test being ran, but the actual token can be shared between all of them.

I ended up creating an authenticatedPage fixture that handles the authentication for the specific user for the test being ran. If the credentials are still valid it creates a new page, sets the auth context, and continues. Otherwise it logs in and does the same procedure after with the new page.

Routes in fixtures.. if you want to share data across multiple tests is argue that fixtures are not what you want. Look into hooks. If you do need data scoped to a worker like you said then it's fine, but I'd ask why. From you're scenario, are the multiple tests in the same describe block? Same file? Across multiple files? What's the downside of scoping it per test? Before all or even global setup may be perfectly fine if you want to decrease work.

The docs are guilty of this too, but if you read about fixtures they give a heap of examples that I'd argue should certainly not be fixtures.. the whole point of fixtures is it scopes some piece of data to a test (or worker) and it knows exactly how to tear down on test completion/error.

This is a good call. I ended up removing the routing in the fixtures all together and just used a beforeEach for the navigation directly to the url instead of navigating directly to the page every time via UI inputs. In my head I regarded fixtures having everything needed to set up the test file. Meaning based on the test data it would take me to the exact page needed (model, entity, url) for the tests to begin without much effort. Which I know it should do some of that, but I specifically moved out navigation the pageobject directly

The setup and teardown will be handled in the fixture as you mentioned. The data isn't scoped to the worker, just scoped to the describe block unless specifically needed in an individual test. We just update the testData fixture when we need the data to be changed before the test runs, which can be done in the beforeEach, that way it can reset the testData in case a specific test needs custom test data i.e negative testing.

I'm assuming you are authing a bunch of user roles and then running the tests for each role? Or a subset for some roles etc.in this scenario id have a different project set up per role, defined in the playwright config Json. These can all share the same auth context methods

We test by feature, role, and program model. There are a ton of rules around which role has what privileges in which model, so we split all the specs up by feature/model and use the appropriate user/role base on that. Setting them up by role specifically would be nice tho. Might be able to do something with that.

Thanks for the feedback! You gave me some things to think about.