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.
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.
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. :)
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
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.
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.
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. :)
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.
Like for the video! I'm really wondering people write: "Hey. It's interesting approach. But what if I have 100500 cases with 100500 pages?" Guys, the silver bullet for all of you current own projects doesn't exist. Unfortunatly))
Precisely - this is where POMs fall short big time. For any somewhat serious product, the number of different page objects gets out of hand very quickly. :) And you're 100% right, there's no silver bullet, and there will never be one. 🦝
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. 🤷 :)
That's of course an option, too. I don't hold strong opinions on how to structure POMs and constructors. But I do like to use fixtures and Playwright's native dependency injection. 🦝
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.
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 !
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. :)
@@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.
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. 🤷
You say you usually don't like page object models. Do you have a video on what you like to use? Or can you at least give me the name so I can look into it?
Usually I prefer to group functionality based on user actions instead of pages. I also don't like to initialize new page objects all the time. 😅 As an alternative, I quite often have `user.login`, `user.logout`, ... object methods which I bring in via Playwright fixtures. This objects aren't necessarily bound to specific pages but rather a set of functionality. Of course, this approach is no silver bullet but I like it better than POMs. :) I'll put this topic onto the list of ideas for future videos. Thanks!
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".
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
@@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?
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.
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.
@@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
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. 💙
Good to see that I am not the only one doing this approach :-)
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. ;)
Omg, this is a game changer, i moved from selenium to pw, and didn't understand at all how to implement fixtures correctly
Happy to hear the video's been valuable. 💙
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?
What is your repo link
Beautiful mate! What do you think about the approach of using a PO Manager?
Hmm... I'll have to do some reading about this. What's a PO Manager? 😅
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 👍
Just implemented, what a nice hack 🙏
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
A really beautiful solution, nicely supporting the SOC and SRP coding principles!
Thanks!
Great tip - as so often with your videos. Thank you so much!
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! 📽️
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
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.
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.
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. :)
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.
Excellent video. I became a fan of yours. 😊. Thank you
Like for the video! I'm really wondering people write: "Hey. It's interesting approach. But what if I have 100500 cases with 100500 pages?"
Guys, the silver bullet for all of you current own projects doesn't exist. Unfortunatly))
Precisely - this is where POMs fall short big time. For any somewhat serious product, the number of different page objects gets out of hand very quickly. :)
And you're 100% right, there's no silver bullet, and there will never be one. 🦝
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. 🤷 :)
From all the annoying maintenance needs I guess maintaining the fixtures is the easiest part
Why not making the login method, instantiate and return the dashboard page?
That's of course an option, too. I don't hold strong opinions on how to structure POMs and constructors. But I do like to use fixtures and Playwright's native dependency injection. 🦝
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?
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.
@ninkambli @Xelvise I don't know why, but my comments with links or even GH repo name are deleted instantly here
@@dva_kompota hmm... We didn't delete anything. I'll look into it maybe there's a misconfigured setting.
How about usong cucumer and Playwright? Is it good approach?
Unfortunately, I haven't used Cucumber with Playwright, so I can't tell if it's a good approach.
@ChecklyHQ i tried but had problem to run it, so abandoned this solution
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. :/
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! 📺
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. :)
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. 😅
@@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.
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. 🤷
You say you usually don't like page object models. Do you have a video on what you like to use? Or can you at least give me the name so I can look into it?
Usually I prefer to group functionality based on user actions instead of pages. I also don't like to initialize new page objects all the time. 😅
As an alternative, I quite often have `user.login`, `user.logout`, ... object methods which I bring in via Playwright fixtures. This objects aren't necessarily bound to specific pages but rather a set of functionality. Of course, this approach is no silver bullet but I like it better than POMs. :)
I'll put this topic onto the list of ideas for future videos. Thanks!
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".
This one's great! And so simple
Thanks!
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
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)
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?
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.
I'm not sure I follow. This video wasn't about saving time, or was it? Could you explain a bit further?
@@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. :)
@@ChecklyHQ I meant saving time in terms of coding, yes. Thanks for answering :)
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.
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.
Thank you 😊
Super Cool Love it
This would be useful in playwright cucumber context. right?
Good question and unfortunately I don't know the answer, bc I haven't used Playwright cucumber yet. 😅
looks like timeouts (action , test timeout , expect) are not working with fixtures . anyone faced this issue ?
Without an example implementation or code examples, it's very hard to help.
That said, I haven't had any issues with this approach yet. :)
Thsnks a lot!
super cool!
Happy the video's been valuable. :)
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 )
Cool stuff
What is name vs code themes?
I use the `Yi Dark` theme. :)
you rock!
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
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. 👍
problematic design
@@jjjjjj6322 can you explain?
@@ChecklyHQHe cannot, because it's not a problematic design. Good job!
thanks for the greate content
Thank you! Happy it's been valuable.