Playwright Core API

If you've used any agile script testing framework in the past, the playwright API is going to be pretty familiar as it provides a commonly used test and expect functions. The test and the expect functions are exported from the playwright test package. This is great when compared to other frameworks because it is not global, which means that it'll not conflict with other global frameworks that you might have, like moca or jist. We use the test function to create a new test. The first argument is going to be a string, which you can use to describe the test, and the second argument is going to be a function which will be used to execute the test.

A great thing to note about playwright over here is that it supports JavaScript Async Await within the test body. You can follow the AAA testing pattern, which is arrange act and assert. So here we are arranging two variables. Then we are acting by simply summing those variables and then we are asserting that the sum is equal to the expected value. Now let's go ahead and uh, run this test to demonstrate that it works as expected. And one thing that you are going to note is that this test is going to run blazingly fast. It's only taking five milliseconds. You could write a simple unit test in any testing framework

like just or moca, but what sets playwright apart is its support for web browser fixtures. So let's work on another spec file called Google Do spec ts. This time when we create our test within the callback function, we destructure the page member from the past in argument. This is called a fixture and the page fixture. Let's play right Note that in order to execute this particular test, it needs to create a page instance. This page object can be used to interact with a single tab within the browser. For example, we can navigate the tab to google.com. Now, when we execute this test, playwright will go ahead

and launch the browser and give us a page object, which of course we will use to navigate to google.com. One magical feature of playwright worth noting is that fixtures are only created when they are requested. So in this particular case, since we asked for the page fixture, the page was created and that is why this particular test is going to run slower than the simple unit test and it's taking around 1.9 seconds. The way you interact with portions of a webpage with playwright is by using locators. And the simplest way to locate something on a page with playwright is to use CSS selectors to demonstrate locators.

We are going to be using google.com and knowledge of the HTML structure of the website is definitely going to help us in our automation journey. We are going to be sending some text to the main search input, and if we inspect that particular element, notice that it has a title attribute. With the value search, we are going to be passing title equals search to the playwright locator. And then once we have it located, we are going to be typing in some text, for example, playwright, followed by the enter key. This should take us to the results page, which should have the title playwright dash Google search. The way we create a locator is

by using the page locator function, and at its simplest it takes a CSS selector. So here we are simply selecting anything that has the title attribute of search. The locator Provides various methods that can be used to interact with the element. For example, we can type in some keystrokes by using the type method and to send special keystrokes, we can use the press method. For example, here we are pressing the enter key. The expect method within playwright is actually quite powerful as well. For example, we can expect that the page should have a particular title. Note our usage of the await keyword.

It allows us to pause the execution of the test till a particular condition is met. For example, we do not proceed till the navigation to goal.com has been completed. Similarly, we do not press the enter key till the complete keystrokes of playwright have been sent to that input. And also with the expect we keep waiting till the title of the page changes to the desired result. Now let's go ahead and execute this test to see it in action. We visit google.com and within the input we type in playwright, followed by the enter key, and then we make sure that the title of the page is updated.

Playwright automatically tracks the amount of time it takes for each of these steps. For example, the Go-to took 1.3 seconds. The input interactions took 45 and 180 5 milliseconds, and the final title assertion only took 12 milliseconds. One of the key issues with end-to-end testing is flakiness, and the key source of flakiness is trying to carry out an action when the web application in the browser is not yet in an expected state. Modern frameworks like playwright get around this issue by being smart about when they carry out an action with automatic waiting and automatic retries.

So as an example, if you modify the locator to be something that does not exist on the Google homepage, for example, title equals searches and then run the test again, playwright will keep trying to find an element that matches that particular requirement and not immediately fail on the input stock type action. After it has waited and retry to find an element that matches that description, the test will eventually fail. You can see that this particular test took 30 seconds to run. So for 30 seconds playwright kept trying to find something with the title searches, and eventually nothing was found

and the test terminated. Unsuccessfully. With playwright, you can modify the default timeout of 30 seconds after which the test will exit by using a config option within the playwright configuration file. So within our playwright config ts, we can set on your timeout value, which is in milliseconds. For example, here we are setting the timeout to be five seconds. So now if you run our incorrect test again, you will see that it will fail much more quickly and in fact fail after five seconds. In addition to a global timeout, we can set a specific timeout for an individual test as well

by using test set timeout here if you've modified the timeout to be two seconds. So now if you run this test again, it'll fail even more quickly and actually specifically at two seconds. Most commonly, you will not need to modify the timeout as it only comes into action when there is a failure. And a 32nd is a reasonable duration to take into account any weird network and application code. Timing issues.