Playwright Test Fixtures

One of the most powerful features of playwright is the concept of fixtures. Fixtures allow on demand access to core features that we use for testing like the page object within playwright fixtures are the things that we destructure from the test function arguments. Right now we have a test that does not take any fixtures and therefore when playwright is going to run this test, it's going to run extremely fast because playwright doesn't have to do much work in order to start executing our test. So you can see that this particular test takes only a few milliseconds to execute. Now let's create another test

and ask playwright to give us the page fixture. And now if you execute this test, playwright will first have to create a page for us and therefore this particular test is going to take much longer. As you can see, it takes around 200 milliseconds because playwright has to create the page before it can start executing our test. In addition to the page playwright only comes with a handful of additional fixtures and these shed some light on the internals of playwright as well. Another fixture that we've looked at in a previous lesson is the request fixture, which can be used to make HTTP requests. For example, here we are making a get request

to local host 3000 API. Hello, and then logging out its response to the console. So if you execute the test and then reveal the test output, you can see the response printed in the console, which is simply, hi there. Another fixture that can come in handy if you want to do some browser specific stuff is the browser name, and this will simply be chromium Firefox or web kit depending upon the browser that is currently executing our test. As you can see in the output of this test right now, this test is executing using chromium. An important concept in playwright is the distinction between a browser context and page

and the relationship between them. All of these are available as fixtures as well. When we request a page, the first thing that playwright has to do is to create an instance of the browser as a demonstration. Let's just log out the version of the browser that playwright is currently executing. The next thing that playwright has to create is a context and you can think of a context as an isolated browser window. From the context we can get access to the attached browser and from that we are again printing out the version. And finally, from the context playwright creates the page and you can think of that as a tab within a browser instance

and we can travel up the chain from page as well going to the context and then the browser and finally printing out the version. The reason for the separation is that it allows playwright to create new instances of the page without having to fully recreate a browser or a context from scratch. We can actually do all of this work ourselves as well and create a page by using the browser. We accept the browser fixture, then use its new context method to create a context and then use the new page method on the context to create an instance of the page. And once more, we use this page object to look at the context and then the browser

and then print out the version. Now one more thing that we need to do when we create the page ourselves is called page close. And while for most use cases, you do not need to know this insight into the mind of playwright, it is good to know how it actually works. Now let's go ahead, open up the Terminal and execute the spec file. And as you can see, all of these tests print out the same version in addition to the built-in fixtures that come with playwright, we can also define our own custom fixtures and this allows us to make our tests more domain specific so it really starts to feel like we've taken

what playwright provides and build our own custom testing framework. On top, we create a new file called Test Ts within the test details folder and we bring in test from playwright slash test and rename it as base. The reason why we rename this is because we will be exporting our own custom test function that extends the base with additional fixtures. The fixture that we intend to create is going to be for the do page. So we bring in the do page that we previously created in our page object model tutorial. Next, we export this new custom test function which extends the base with an additional fixture to do page,

which is going to be off the type to do page class. The extent function takes an object and each member of the object is a custom fixture that we want to add to the original playwright slash test function. Since we said that we were going to provide a to-do page fixture, that is exactly the property of the object that we set. Each custom fixture definition is going to be a function in itself and this can in turn depend upon are the fixtures. For example, the to-Do page fixture depends upon the provided page and the request fixtures built into playwright.

A second argument to the fixture definition function is use and use is what we will utilize to provide the to do page fixture to any test. That request is within the fixture definition function. The first thing that we need to do is to perform any setup before we can provide the fixture to the test that is requesting it for the to-do page. We create a new instance of the to-do page class and then invoke its method clear to twos and visit. This gives us a nice clean, fresh two page which we can then provide to the test that was requesting it by utilizing the use function. We await for the use function to wrap up

and once it is done we can perform any tear down with a fixture that we want to for our particular to do page fixture. We don't need to perform any tear down and therefore we don't have any further statements within this fixture definition. As you can see, we are exporting this new custom test method that we have extended from playwright slash test. The other common import that we use from playwright test is expect and just for convenience, we re-export expect as well from the same module so people can bring in test and expect. From this custom test detail, we create a new spec called Custom fixture Respect or ts, and then we bring in the test

and expect modules from the test details test file that we just created. With this custom test that we created, we can actually request the additional fixture that we had, which is called to-Do page. And because of our setup for this custom fixture, it gives us a new to-DO page already visited, and with any previous to-dos already cleared. This means that we don't need a tester before each and you can simply start adding to-DOS and expecting them. On the to-Do page, this custom test function is also picked up by the playwright tools within Visual Studio Code. So let's go ahead and run this particular test.

And as you can see, everything works as expected. We have two to-do items added to the page.