Reuse Playwright Code across Files and Tests with Fixtures 

We're very happy that this video has been helpful! 💙

Thank you for the kind words. Happy the video has been valuable. 💙

Happy you found it after all. :)

Glad it was helpful! 💙 Thanks for watching!

Thanks! Happy it's valuable! 🦝

Thanks Ross. I'll put it on the list for the future videos. :)

The color theme is Yi Dark and if you're after the custom font it's described in this article 👉 www.stefanjudis.com/blog/how-to-enable-beautiful-cursive-fonts-in-your-vs-code-theme/

Custom fixtures aren't bound to a single one. You could add more if you wanted to. :) Add more properties to the `extend` object and you're good to go. :)

@@ChecklyHQ cool. Thanks for the reply :-).

Glad it was helpful!

We think so, too! 💯

Yes, this is correct. There's nothing particularly wrong with importing utils/poms within your test files. But I found that by relying on fixtures a project becomes more structure and does things "the playwright way". One advantage is that if you're using classes that need to be initialized you can hide this and don't neet to care about it. :) 👇 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-k488kAtT-Pw.html

@@ChecklyHQ Thank you for your reply, appreciate it! Speaking about initializing classes... we already hide them with pageManager. There is a function, that returns class object, so we call that function in test file. I agree about "the playwright way". Looks like there are few ways to achieve same result. Agree, that fixtures look nice. And thanks for sharing your tips and playwright insides. Before fixtures were unclear to me... but now I understand them a bit better. Thanks for your effort!

@@glebmirosnikovs6722 Oh for sure - there are plenty of ways to abstract things. :) Playwright is also just JS/TS at the end. Happy to hear that the videos have been valuable. If you have more questions or comments, I'm always looking for new ideas. ;)

That's right Guillaume and a great question. In this simple example scenario, a helper method definitely works. 👍 Fixtures enable you to follow the PW conventions and group helper/utility code like the framework does. I consider this to be a great advantage. Additionally, and considering your example: if you'd want to perform a teardown action (maybe you want to log out after) you'd already have two methods to pull in every test case and the number of util functions grows. With a fixture-based approach, you could put setup (before the 'use' call), the action and teardowns (after the 'use' call) into a single place. Hope this helps. :)

Thanks!

This is a great question and I think I'll record the answer today. :)

And here we go: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-rRmfYu8hlbw.html 😊

@@ChecklyHQ thanks, before I saw it , my solution for this was global params like: process.env.userName

Thanks Aleksandar. I don't think it's an either-or decision. Fixtures play nicely with POMs. I see their main advantage in being to use "native PW functionality" and the ability to have setups / teardowns next to the code running in your tests. So if you're POMs have some sort of required clean-up steps, i'd def go for a fixture setup. Hope this helps!

@@stefanjudis I am using fixtures to create POM objects, e.g. myAccountPage: async ({ page }, use) => { await use(new MyAccountPage(page)); }, so that I don't repear this useless code every time in test script

Thanks! Happy it was useful! 😊

Nothing wrong with writing your own abstraction. 👍 Fixture are just the more native way of doing things. :)

The editor setup is described here: www.stefanjudis.com/blog/how-to-enable-beautiful-cursive-fonts-in-your-vs-code-theme/

@@ChecklyHQ thanks so much

@@ChecklyHQ thanks u rock!

Glad it was helpful!

No, unfortunately we don't have and are not planning to create a course on that. :/

Thanks! Happy it's useful. :)

Great question, Costa. Yes, this is possible with `test.use()`. playwright.dev/docs/api/class-test#test-use

@@ChecklyHQ Thanks I found a solution where I create a baseFixture that holds everything that is common to all my tests and then I have fixtures that extend the base fixture that targets a subset of tests and its working perfectly. I did try the test.use() but in my use case it did not work

@@CostaGiannakopoulos That's great to hear? What were the issues with test.use()?

@@ChecklyHQ I was getting conflicts in the api request where 1 of the 2 requests was bad as they conflicted, so iv separated the conflicts into 2 new fixtures that both extend from the base so i dont have to duplicate the common stuff

@@CostaGiannakopoulos Great. Thanks for explaining!

That should definitely be possible. I'll put it on the list for future videos. :)

It depends on the case I'd say. If you have a single `spec` file before/after does the trick for sure. And also, when it comes to saving the login logic, you also make a valid case buy saving the browser state. All that said, I often prefer fixtures, because they "hide" functionality from my spec files. I don't have to worry about fiddling with before/after or anything. Additionally, I can also configure them with fixture options. Implementing fixtures just feel like a "native Playwright approach". And I like this a lot. But, of course and as always, it's a classical "it depends" and a matter of taste. ;)

Glad you enjoyed it. Thanks!

Hey Dániel, I just had a look and I don't think that's possible. But if you're testing your sites with two different states (such as a regular and admin one) I'd also favor fixtures. `test('something', ({page, AdminPage})` Hope this helps. :)

@@stefanjudis thanks, i am doing this now, my test login admin... logout admin login editor... logout editor login admin, that i can delete the item what do u suggest how could i avoid so much login,logut?

@@danielkovacs3664 Hey Daniel, in this case I'd login admin and editor so that you don't have to switch and log in/out all the time. Similar to this: `test('something', ({page, AdminPage})` That said though, here at checkly we have a good experience with cleaning up created resources on the API level. blog.checklyhq.com/how-low-level-api-calls-stabilize-your-end-to-end-tests/

Enabling and disabling fixtures doesn't feel right to me. I'd rather make the fixture behave differently depending on run time flags. :) Hope this helps.

You could always structure your project to use different fixture with different exported `test` object. And depending on the fixture differences you could also make fixtures configurable with fixture options. It's a bit tough to give advice without knowing specific. :)

Great call. We'll put it on the list. :)

This doesn't sound like a fixture case for me. I'd instead extract the logic into a separate function for the case of evaluating text in the clipboard. That said, you could always change the fixture to be a nested object or a function. It's up to you what to call `use` with. :)

You can create a similar fixture called "accessToken", do whatever needs to happen to access the token and then pass it to your tests via "use(token)". Hope this helps. :)

@@ChecklyHQ ok, Thanks, That was a quick help. at the same time another question I have json(playload) stored in a file and I want one Field (RefNumber) has a random value every time How can I provide a random value every time to the RefNumber in json? for exmple in follwing workOrderPayload is the work load and I was to provide RefNumber as a random to the Json everytime const response = await request.post(workOrderUrl, { headers:{ "Accept" : "application/json, "Content-Type" : "application/json "Authorization" : `Bearer ${process.env.TOKEN}` }, data: workOrderPayload })

@@salikhanan I'm not sure I understand. Could you use `Math.random()` and alter `workOrder` to include a different `RefNumber`? That said though, let's stay focused on this video here. :) For questions around synthetic monitoring with Playwright and Checkly we're always happy to help at checklyhq.com/slack/. :)

Try native Authentication solution from Playwright well described in the docs

It's FiraCode iScript and if you're looking for the same editor setup it's described on my blog: www.stefanjudis.com/blog/how-to-enable-beautiful-cursive-fonts-in-your-vs-code-theme/