How to combine POMs (Page Object Models) with Playwright Fixtures for better developer experience
ฝัง
- เผยแพร่เมื่อ 24 ก.ค. 2024
- 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 - วิทยาศาสตร์และเทคโนโลยี
![[TH] 2024 PMWC x EWC Group Stage Day 3 | PUBG MOBILE WORLD CUP x ESPORTS WORLD CUP](http://i.ytimg.com/vi/VnOqutfqWqU/mqdefault.jpg)
Good to see that I am not the only one doing this approach :-)
A really beautiful solution, nicely supporting the SOC and SRP coding principles!
Thanks!
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.
Nice! Let us know how it goes. ;)
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!
Oh thank you! Happy the video's been helpful. 💙
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. 👍
Great 👍
Excellent video. I became a fan of yours. 😊. Thank you
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)`
Yes, that's a great tip!
Can you please give github repo of this example?
Super Cool Love it
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.
Thanks for sharing!
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?
super cool!
Happy the video's been valuable. :)
Cool stuff
you rock!
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?
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. :)
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
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 !
I don't think that's possible unfortunately. :/
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
This is a great question! 💙 Let me research this topic a bit and put it on the future video list. Watch the space! 📽️
Excellent video, which code auto complete plugin you are in Vs Code?
Thanks. It's GitHub Copilot. :)
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?
Can you explain a bit more. Preserving state between tests doesn't sound right. 😅
Please can you make a video on GItCoPilot on Playwright and how to use it in the test environment?
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. 🤷
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.
I'm not really sure I understand. But I abstract functionality with fixtures quite often (with and without POMs).
@@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.
@@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.
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
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".
thanks for the greate content
Thank you! Happy it's been valuable.
Nice video! You said that you don't like to use POM, which other design pattern do you prefer?
This is a great question and I'll put the answer on the "future video list". Watch the space! 📺
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.
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. :)
@@ChecklyHQ Thanks for clarifying
I used this way and it is pretty straightforward. But I think there’s a limitation on BeforeAll hooks
That's interesting. Thanks! Do you have an example of when this approach hits limits? 🤔
@@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)
Nice explanation 👍. The only con I see is all pages getting initialised in one shot which is not good from memory perspective.
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.
How was the runtime if you initialize objects even if you do not need it on a specific test case?
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`.
@@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?
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)😃
Can you explain your method?
Yes, please share anything you come up with. :)
@@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)😅
So you're describing a "super POM" so to say? :D
@@ezraarjunapandi3736 later I'll try to explain and give thr examples) now I'm outdoor )
What is name vs code themes?
I use the `Yi Dark` theme. :)
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();
});
},
);
But then you have to pass the `page` object into `function1` and `function2` or? But as always, there many ways to do things. 👍