Page Object Model Pattern with Playwright

[0:00] Here we have a playwright test, that goes to the basic scenario of working with the to do MVC app within the before each pin, navigate to the to do MVC URL. Then we have a test where we will make sure that we can add multiple to-do items to add a simple to do. We need to get the locator for the new to do input, fill in some text. And then press the enter key. Next. We find all the labels that are within something that has the view class to make sure that the text matches up to the to do that. We add Added. And then to add the second to do and then to make sure that that to do is also successfully added. You might notice that we have quite a bit of code, duplication, additionally, without the comments and some context about the application under question is not entirely clear that. These two statements, add a single to do item. And this particular expectation locator, is going through the list of currently edit to-do items. One additional issue, is that if we ever decide to modify the CSS classes within our UI app, To modify this test spec file as well. The page object model pattern is designed to solve all of these problems. We create a new file called to do page, the Ts that will contain the object model for the to do page. We start off by bringing in utilities from the playwright test module that we will be using to the enough page object class. Now at its core. The to do page class is going to be pretty simple. It will have the locators for the things that we will be interacting with which in our case are the to do input is As well as the to do labels. Now. The next thing that we can do within our to do page object class is to create little utilities for things that we commonly want to do on the to do page. First up is ability to go to that particular page. Next up is the ability to add different dues and finally is an expectation to check that the to do is match what we've added with these Utilities in place. We can jump back to our example, spec file, and clean it up to use this to do page object model. First up, whenever Need to go to the, to do page. We don't need to have this ugly, you are anymore. We can just instantiate a new instance of the DuPage and use its CO2 method more significantly. We can clean up a lot of the code within the first test that we added at the start of our test, whenever we get a browser page from playwright. We use it to create a to-do page object and then the rest of the test spec becomes quite self-explanatory, for example, whenever want to add it to do with a simple call to, to do page dot, add to do, never were. We want to expect to do items. It's a simple call to to do page, not expect to dues thanks to utility methods. A page object model makes your test much more clearer in its purpose. And now, if you ever need to refactor the UI of our application, most of the changes will be handled by the to do page object model, and we would not need to refactor. Our spec files as much.