How to combine POMs (Page Object Models) with Playwright Fixtures for better developer experience

Page object models (POM) are common to encapsulate test automation logic and improve code readability. Learn in this video how to combine POMs and Playwright fixtures for effective end-to-end testing and synthetic monitoring with an excellent developer experience.
Learn more about Playwright fixtures in this video: • Reuse Playwright Code...
Got questions? Join the Checkly community Slack. And tune in next week for more on Playwright, Synthetic Monitoring, and API Monitoring. Happy testing!
Checkly Community Slack: www.checklyhq.com/slack/
Page Object Models in Playwright: playwright.dev/docs/pom
Playwright fixtures: playwright.dev/docs/test-fixt...
0:00 Intro
0:35 Page Object Model example
2:18 Downsides of Page Object Models
2:45 The dream of a perfect Page Object Model setup
3:19 Playwright fixtures explained
3:40 Implementing Playwright fixtures
6:44 Outro
#playwright #checkly #testing #monitoring

[@DiRo0566]

A really beautiful solution, nicely supporting the SOC and SRP coding principles! Thanks!

[@powertester5596]

Good to see that I am not the only one doing this approach :-)

[@3VAudioVideo]

Coming from QTP and then to Selenium, I too hated having to initialize the same objects over and over again. You do such a great job explaining things in a very clear and concise way. Love your channel!

[@ChecklyHQ]

Oh thank you! Happy the video's been helpful. 💙

[@prasannamallisetty7208]

Excellent video. I became a fan of yours. 😊. Thank you

[@rsganesh9443]

Super Cool Love it

[@nikolaljubicic-mijic5193]

This is so great. Sometimes I need to initialize more than a few Object Pages. This is a great workaround. 🤗 I will try this for sure. Keep doing great job.

[@ChecklyHQ]

Nice! Let us know how it goes. ;)

[@og4789]

Super super nice thanks 🙏 I am a big pom fan as I like reusing code and to keep the test case itself short and more readable. I also don’t like the initializing with new all the time, now your solution appeals a lot. I will give it a try soon. 👍

[@ChecklyHQ]

Great 👍

[@magnus6114]

Great video! For those interested in further examples. I've written a small framework (package) which uses this approach to easily create POMs called POMWright (npm/github). Though the main feature is locator management and automatic nesting/chaining of said locators per POM, aswell as handling session storage.

[@ChecklyHQ]

Thanks for sharing!

[@Al-oh9yr]

Hi Brother. Do you have the same sample repo project for PlayWright with BDD frame work java. Do you have a mail id to reach out?

[@andreaskarz]

Cool stuff

[@roblesrt]

super cool!

[@ChecklyHQ]

Happy the video's been valuable. :)

[@_unreal_engineer]

you rock!

[@HelloWorld-xg6nw]

doing exactly the same) Just maybe that now I've changed it a bit to have a container with all pages. Like Pages object that stores all pages. export class Pages { page: Page; signInPage: SignInPage; dashboardPage: DashboardPage; Just because in some complicated e2e tests you interact with too many of them And also it helps to create tests which have > 1 user logged in. So my test looks like ({ adminPages, employeePages }). And sign in happens in setup.ts & fixtures. Very flexible. Perhaps a bit not efficient if you have too many pages in your web site, i.e. 50+. But for my case quite good to follow this approach

[@feralgoose7157]

Thanks, I have a question if I am using test.step() in my tests to organize my navigation and interaction. So, I would have a step to login and check I am on the dashbaord and another step to navigate from dashboard to page1 and then either a aftereach or another step to logout. Is it recommended to have one fixture that instantiates all pages need in a test, or / can we extend the test.step() for each navigation interactions? Currently, I use functions to hide this functionality but would be interested in fixture replacement.

[@ChecklyHQ]

I'm not really sure I understand. But I abstract functionality with fixtures quite often (with and without POMs).

[@emnznlg]

Thank you for the great content! I was wondering why you don't prefer POM and what alternative you use instead. Could you please explain?

[@ChecklyHQ]

My main grudge are the things I mentioned in the video. 1) calling `new` everywhere and initializing all these POMs 2) importing things "outside" the PWT suite. Usually I preferred helper functions (helping to avoid `new` but not with the importing). But now with "Fixture POMs" I think I'll go all in and am convinced. :)

[@filipgajic93]

Hi @Checkly, is it possible to use/import fixtures on test.step level ? I know I can pass it as a parameter to the function from test but I'm wondering is there a way to use it the same way you're using it on the test level? Thank you !

[@ChecklyHQ]

I don't think that's possible unfortunately. :/

[@Uradha1]

Please can you make a video on GItCoPilot on Playwright and how to use it in the test environment?

[@ChecklyHQ]

That's an interesting idea. I'm unsure if we'll do it unfortunately. CoPilot is unfortunately only 50% correct, and I'm on the fence if it's actually useful. 🤷

[@Rehank213]

Excellent video, which code auto complete plugin you are in Vs Code?

[@ChecklyHQ]

Thanks. It's GitHub Copilot. :)

[@TheSgtFoley]

Hey, @Checkly! Thanks for the video! I have a question regarding this approach: let's say I have around 50 POM in my project so should I add them all to my fixture to use across my tests or is there a better approach to do so? For me, it looks like it will be a bit disorderly to store them just like that

[@ChecklyHQ]

This is a great question! 💙 Let me research this topic a bit and put it on the future video list. Watch the space! 📽️

[@maniladevotee3595]

How was the runtime if you initialize objects even if you do not need it on a specific test case?

[@ChecklyHQ]

That's a great question and I just tested it. First, Playwright will run your defined fixture code for each test case separately and no state is shared. Additionally Playwright somehow checks which fixtures you're planning to use and only runs this code. 🎉 If you define a `LoginPage` fixture this code will only run if you're using the `LoginPage`.

[@maniladevotee3595]

​​@@ChecklyHQhello, I was thinking if you have a drop-down component. How do you make the drop down locator dynamically e.g(drop-down-option1, drop-down-option2, etc...) if it is initialiazed inside the constructor?

[@rahulgiri9880]

Nice explanation 👍. The only con I see is all pages getting initialised in one shot which is not good from memory perspective.

[@ChecklyHQ]

Thanks. I understand your concern but this is not how Playwright fixtures work. If your tests don't define that they want to use a fixture, it won't be initialized. So it pretty much should be the same memory consumption. Because the same number of fixtures will be initialized, just in different places.

[@eduardmazur]

I use POM a little bit in a different way, but yours one looks good) I think I'll try to combine both to get something brilliant)😃

[@ezraarjunapandi3736]

Can you explain your method?

[@ChecklyHQ]

Yes, please share anything you come up with. :)

[@eduardmazur]

@@ezraarjunapandi3736 I create folder "support" where create subfolders for every module in app, create 2 classes Methods and Variables for every module. Then i create index file, where crete export variables for every module. And the result of all this I call only 1 import and use only that class variables which is needed in the test file))) i hope I'm clear have explained)😅

[@ChecklyHQ]

So you're describing a "super POM" so to say? :D

[@eduardmazur]

@@ezraarjunapandi3736 later I'll try to explain and give thr examples) now I'm outdoor )

[@Muhammad55597]

thanks for the greate content

[@ChecklyHQ]

Thank you! Happy it's been valuable.

[@tomasgomez1480]

Nice video! You said that you don't like to use POM, which other design pattern do you prefer?

[@ChecklyHQ]

This is a great question and I'll put the answer on the "future video list". Watch the space! 📺

[@harshasuraweera]

I used this way and it is pretty straightforward. But I think there’s a limitation on BeforeAll hooks

[@ChecklyHQ]

That's interesting. Thanks! Do you have an example of when this approach hits limits? 🤔

[@harshasuraweera]

@@ChecklyHQ I got the issue about 1 year back so not sure whether it’s fixed now, it was about context and page fixtures not supporting inside beforeAll hook. I was trying to take few preconception steps into beforeAll but due to the mentioned issue it didn’t work. So I moved them into the test level. (and yes it worked with beforeEach)

[@luckytima2315]

What is name vs code themes?

[@ChecklyHQ]

I use the `Yi Dark` theme. :)

[@hamzawaykonect2016]

even better is to have it like this without putting the page instance test( `testkey | testdescription`, async () => { await test.step('step 1 ', async () => { await OnePage.function1(); }); await test.step('step 2 , async () => { await OnePage.function2(); }); await test.step('step3 ', async () => { await OnePage.function2(); }); }, );

[@ChecklyHQ]

But then you have to pass the `page` object into `function1` and `function2` or? But as always, there many ways to do things. 👍