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!
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.
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. 👍
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. :)
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.
Hi , I have scenario where after clicking on link on homepage it opens another window tab (page= createOrder page)To interact with createOrder page I need to create another page1 ( created by using waitforevent(popup) )and I passed this Page1 in const createOrderpg = new CreateOrder(page1) but in case of using fixture I am creating an object of CreateOrder inside fixture , how can I pass Page1 into fixture to create object of CreateOrder in fixture
I don't think, if I understand you correctly, `CreateOrder` can be used as fixture then because it's the result of previous interactions. For the case you describe, I don't think it's a big deal to create a new POM, though. 😅 So, the described approach is more for "base fixtures" that you set up at the beginning of your test.
Hi great video! I am using playwright with Js. But i cant directly do ctrl+click on the functions that i am using within my test case while using fixtures For example login is a fixture Login.enterName(); dosent take me directly to the function defination. Would you happen to know or give any inputs of how i can resolve it? Just to enhance devleoplement experience and directly going inside the function.
If your current tests are based on JS, you should be able to rename them to TS and everything should still work. :) But if you don't want to switch, most editors have a type check option even for JS files. I'm unsure if this will solve your issue, but in VS Code you can turn on "checkJS" and this should give you some TS functionality even for JS files.
Would it not tightly couple the Page Objects using Custom Fixtures and create another "thing" to maintain? It sounds like instantiating the Page Objects in tests actually reduces maintenance, since a developer would only have to maintain code in two places, i.e. Page Object and Test, rather than three with the inclusion of a Custom Fixtures.
Sure - that's right. :) If you consider files as "places" to maintain: without fixtures, you have your POM file and the test. With fixtures, you have the POM file, your setup, and your test. On the other hand, if you consider code to write, you'll quickly discover that using fixtures will lead to less LOC because you don't have to initialize them over and over again. As always, it's a matter of tradeoffs and preference. 🤷 :)
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
Use the fluent interface pattern and init the POMs in the POM layer. Then you would only need to init a few entrypoints (e.g. LoginPage) in the BaseTest class
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 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.
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. :)
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 !
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. 🤷
@@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.
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?
As of now I've seen two approaches to this problem. 1) use `mergeFixtures` -> playwright.dev/docs/release-notes#merge-test-fixtures 2) start grouping your fixtures in a huge object e.g. `ui.login`, `ui.cart`, `api.featureA`, ... I hope this helps and I put this topic onto the list for future videos. :)
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
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. 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.
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.
@@ChecklyHQ I guess those workflows got to be convinient, and compared to original POM without fixtures - it doesn't rly help much (I explained why in the first comment). I asked a question to understand if there's a way to make workflow in the video more convinient. If there's no way to acomplish what I asked, or you don't know it - so be it. Not sure what confused you in the first place :)
@@vnukoded Playwright is all about parallelization, and you can't parallelize with beforeEach/afterEach (more context here: github.com/microsoft/playwright/issues/9948#issuecomment-957328762) As a result, fixtures can't be used in beforeEach/afterEach. My confusion came from "saving time", should this mean execution time or coding? And it sounded like this video talks about saving time, which it is not. :)
Okay, I actually missjudged this approach. I can now import tabs/pages/components once, and then use them where they are needed without importing them over and over again. It saves me a lot of time (and nerves) and makes code prettier.
@@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)
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?
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)`
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.
@@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)😅
hey man great video! Hopen you can help me out: i have multiple applications. Application A and application B. Both have a loginPage. Whats best way to make a difference between these applications and call the right loginpage without changing the name of loginpage. I was thinking to call them like A.loginPage B.loginPage then A.loginPage.fillemail() OR call like applicationA applicationB then A.loginPage.fillemail() Hope you can give me a nice solution
Thank you! I'll put this topic on the list for future videos. In your case, I'd start merging fixtures into "fixture objects". So that you'd have `applicationA.loginPage` and `applicationB.loginPage`. There's also some helper utils from Playwright to do exactly this. playwright.dev/docs/release-notes#merge-test-fixtures
