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

Рет қаралды 7,187

Күн бұрын

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....
Page Object Models in Playwright: playwright.dev...
Playwright fixtures: playwright.dev...
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

Пікірлер: 88

@3VAudioVideo 4 ай бұрын

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 4 ай бұрын

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

@powertester5596 4 ай бұрын

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

@vnukoded 8 сағат бұрын

Is there a way to not pass it to every test but to pass it to "beforeEach" or "beforeAll"? Otherwise it doesn't really saves time if you have to pass those args to every test in every testsuite.

@DiRo0566 2 ай бұрын

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

@nikolaljubicic-mijic5193 4 ай бұрын

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 4 ай бұрын

Nice! Let us know how it goes. ;)

@magnus6114 2 ай бұрын

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 2 ай бұрын

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?

@mohamedahmed-xh5eu 15 күн бұрын

Thanks for this video. That's really helpful. How would this work if we have more than 30 fixtures? Should we create multiple files similar to the base file, or is it ok to group all fixtures in one place eg. base.ts?

@user-ki8ij8xi9c 13 сағат бұрын

Thsnks a lot!

@og4789 4 ай бұрын

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 4 ай бұрын

Great 👍

@kiranbgowda27 21 күн бұрын

Hi, i have a doubt what if newPage opens after you did some operation on home page and you need send that instance to next page like cart page. How to send that newPage to another fixture.

@ChecklyHQ 21 күн бұрын

Yes, you're correct. If your applications opens new pages / windows then this approach can become tricky. You could still import the POM in your code and initialize it manually, though. :)

@kiranbgowda27 21 күн бұрын

@@ChecklyHQ Thanks for clarifying

@lukecage9964 Ай бұрын

Imagine to have a big amount of page-objects, it should be really boring to add all of these in the fixture to be exported.. in base.ts is it possible to create the MyFixtures and the export const test dynamically? I mean, like reading all the the pages inside /pom and forEach page add it into MyFixtures and into the test const to export

@ChecklyHQ 28 күн бұрын

Yeah, reading files should be pretty straightforward, but having the correct types will be tricky if you're writing TS. I'm not sure if one could dynamically create the types without bringing in some "build magic".

@TheSgtFoley 2 ай бұрын

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! 📽️

@prasannamallisetty7208 4 ай бұрын

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

@HelloWorld-xg6nw 4 ай бұрын

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

@dva_kompota Ай бұрын

You can go even further: wrap all your page objects into UI fixture and use only it in your `test('test-name', async({ui}) => {}` statement. So in your test you'll have statements like `await ui.loginPage.login(EMAIL, PW)` and `await ui.dashboardPage.isReady()` And even further - you can do the same thing for APIs, wrapping all you API objects with CRUD and other methods into API fixture to do things like `await api.user.create(EMAIL, PW)`

@ChecklyHQ Ай бұрын

Yes, that's a great tip!

@ninkambli 28 күн бұрын

Can you please give github repo of this example?

@Xelvise 12 күн бұрын

It would be a lot more helpful if you could write all of these in a GitHub gist with clear description. Or, better still, put it all in a repo and share with us your Username or Repo URL. That way, we'll better understand how to implement your suggested technique.

@dva_kompota 8 күн бұрын

@ninkambli @Xelvise I don't know why, but my comments with links or even GH repo name are deleted instantly here

@ChecklyHQ 8 күн бұрын

@@dva_kompota hmm... We didn't delete anything. I'll look into it maybe there's a misconfigured setting.

@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).

@feralgoose7157 Ай бұрын

@@ChecklyHQ Maybe another question... In the POM, if I have a button.click() on one page, but we want to ensure that maybe network traffic completes prior to checking if the next page is ready. So the interaction between the 2 pages are tightly coupled and maybe we want a toPass() to be used. I know this is a huge edge case, but we do have instances that the button.click() can timeout, since the network traffic is not responsive based on cold app pools. I don't like the idea of having one page know about another page. Does it make sense to create a workflow object to combine the logic so that each page is single responsibility? Rather than breaking the logic in the POM.

@ChecklyHQ 29 күн бұрын

@@feralgoose7157 I'm not sure I understand and YT comments aren't the best medium without seeing code examples. 😅 But your case sounds like you might want to look at your application. If your page looks ready but isn't and Playwright is too fast, then you might want to check the included UX flaws.

@filipgajic93 2 ай бұрын

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 2 ай бұрын

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

@Uradha1 2 ай бұрын

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

@ChecklyHQ 2 ай бұрын

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. 🤷

@emnznlg 4 ай бұрын

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 4 ай бұрын

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. :)

@christiangibbs8534 Ай бұрын

Nice clean code, but is it possible to preserve state between tests if you are automatically creating a new instance every time you call it?

@ChecklyHQ 29 күн бұрын

Can you explain a bit more. Preserving state between tests doesn't sound right. 😅

@056479335 20 сағат бұрын

@@ChecklyHQ I agree, each test should be self contained and not use states created in other test but I see the point of saving a state from other tests. Imagine that you have two tests. One creates an account and the other on for login. Lets say that the create-account-test generates a GUID that the login-test wants to check.

@rahulgiri9880 3 ай бұрын

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

@ChecklyHQ 3 ай бұрын

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.

@tomasgomez1480 2 ай бұрын

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! 📺

@rsganesh9443 3 ай бұрын

Super Cool Love it

@harshasuraweera 4 ай бұрын

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

@ChecklyHQ 4 ай бұрын

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

@harshasuraweera 4 ай бұрын

@@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)

@Rehank213 4 ай бұрын

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

@ChecklyHQ 4 ай бұрын

Thanks. It's GitHub Copilot. :)

@maniladevotee3595 4 ай бұрын

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

@ChecklyHQ 4 ай бұрын

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?

@roblesrt 4 ай бұрын

super cool!

@ChecklyHQ 4 ай бұрын

Happy the video's been valuable. :)

@andreaskarz 4 ай бұрын

Cool stuff

@eduardmazur 4 ай бұрын

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 4 ай бұрын

Can you explain your method?

@ChecklyHQ 4 ай бұрын

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

@eduardmazur 4 ай бұрын

@@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 4 ай бұрын

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

@eduardmazur 4 ай бұрын

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

@_unreal_engineer 4 ай бұрын

you rock!

@luckytima2315 4 ай бұрын

What is name vs code themes?

@ChecklyHQ 4 ай бұрын

I use the `Yi Dark` theme. :)

@hamzawaykonect2016 2 ай бұрын

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 2 ай бұрын

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