Integrating Playwright Into Web Applications

Playwright comes with options to launch a local web app before running your tests. And this makes it super easy to integrate playwright into any standard web development workflow. To demonstrate that we create a new JavaScript application and you can do the same workflow with any React or Angular or view or any other framework application that you might have. But here we are creating a basic vanilla one so that it is completely platform agnostic. We have used the command NPM in IT Beat to create a new Vanilla RA application. We CD into the application that has been created and run NPM install to install all the dependencies.

Now, the development workflow for this application is that we need to execute NPM Run Dev to start a local development server and this particular sample starts a live preview of our app at local host 5 1 7 3. And if you open up this URL in the browser here, you can see this brand spanking new application that we just created. It has a simple heading in a simple counter. Now to ensure that our application continues to function as expected, we need to understand the generated HTM structure of our application. The heading that we are looking at is a simple H one containing the text wheat plus type script.

And if we inspect the count button, it is a simple button with an ID counter that currently contains the text count is three. This text is going to be dynamic and it's going to continue to increment every single time the counter button is clicked. Our mission is to add integration tests to make sure that the heading is always going to be there and the counter is going to behave as expected. Now that we have a sample web application, let's take a look at how we can add playwright into this app and the steps are going to be the same for any JavaScript or TypeScript web application. We open up this project within Visual Studio Code

and execute the command NPM in it. Playwright. This is the same command that we previously saw when creating an empty playwright project and the same command is being used to add playwright to an existing project once the command completes playwright has been integrated into this project. We have the new test folder, which we previously saw as well, which contains a simple example spec. We have the test examples which contains additional tests if you wanted to use them. We have no use for them, so we will go ahead and delete it. And then within our package to Jason, you can see that we have playwright slash test installed.

Within the script section, we can add a new item called test that allows us to conveniently execute playwright test with a few default arguments. We covered the various arguments like reporter project and headed in our lesson on playwright CLI. One final thing worth noting is that a playwright config file has also been created for us just like it was done for an empty project. In order to integrate playwright into the development workflow so that we only need to run the playwright command to automatically start the app, run the tests, and then exit the app, we need to use the web server option in our playwright config.

At the bottom of our playwright config, we add the web server option for this particular application, we started At NPM Run Dev and then we visit the local host 5 1 7 3 URL. So these are the two options we are providing to Web Server. Now whenever we try to execute the playwright tests, it'll automatically execute NPM Run dev and wait for something to listen at URL 5 1 7 3. Before continuing with our test, let's open up the test folder and write a brand spanking new example test. We bring in the usual inputs from playwright test,

which are test and expect. A neat thing to note about the playwright API is that we can use a feature called test before each to execute a particular function before each test. Here we are using page do Go two to navigate to local host 5 1 7 3 before each test so that we don't need to have the statement in every single test. The first thing that we want to verify is that the heading should be visible. For this, we use the locator to find an H one and the locator can actually take additional options as well. And one option is has text, so we want to find some H one that has the text Wheat plus type script,

and then we simply expect that this particular heading should be visible. That's it for the heading. The next thing that we need to test is the behavior of the counter component. Here we are introducing another feature of the playwright, API called test or describe. This can be used to group multiple tests which all relate to a particular item within the callback. For describe, we define our additional tests. The first test for the counter is that it should be visible. For this, we simply locate the counter by using a CSS selector for its id, which was counter, and then we expect

that this particular button should be visible. The next thing that we want to ensure about the counter is its incrementing behavior. So we start off by locating the counter and ensuring that it starts off with a text count is zero. Next, we trigger a click on this locator by using the click method. This should result in an update on the text of this locator and we can expect that the new text should be count as one. And now for the moment of truth, we open up the testing panel and execute the tests. Now don't plank because the tests are going to execute extremely fast

and no surprise all of our tests have completed successfully. And these tests will continue to ensure that the current behavior of our application continues to function as we add more and more features to our app. Quite often during development, you will have the web server already running because you are working on the website. In such a case, the default behavior of trying to run the playwright test will result in an error as it'll complain that the server is already running. To fix this, we can simply enable the option reuse existing server. To demonstrate this, let's pretend

that we are working on the app and we execute NPM run dev ourself. Now of course, if you visit local host 5 1 7 3, you can see that our application is running while we have this application started. If we try to run the test again, you can see that it errors out because local host 5 1 73 is already being used. This is a defense mechanism built into playwright to make sure that we do not accidentally end up running our tests against a server that we did not expect. Since we do not expect to be running anything else on local host 5 1 7 3, we can inform playwright that it is safe to do so

by using the option reuse existing server and setting its value to True. And now, if you try to execute the test again, even though we have NPM Run Dev running in the background, playwright will happily execute our test against an existing server. There are a number of advantages of having playwright embedded in the same code base as our web application. And a key advantage worth pointing out is the fact that we can share the application code in our tests to increase the maintainability and reduce the flakiness of our integration. Within the source folder of our application, we create a new module called Copy.

Here we will create any text that we plan to use between our web application and our playwright test. For example, here we can export the heading Text that is going to be used by our web app as well as by our playwright test. First we jump into our web application within main Ts. We bring in the heading text from a copy module and then ensure that this is what is being used to power the H one. And now that we have it in place, we can use the same variable within our playwright test as well. So we jump to our example spec and bring in the heading text from our source copy module. And then within our test, instead

of hard coding Wheat plus TypeScript, we use the heading Text variable, which is being shared with the application code. At this point, no functionality has changed between our application and our test, and if you execute the test, you can see that it still passes. The key advantage of sharing the code is that as the business requirements change, we will not have to modify our test to ensure that the new business requirements are met. As an example, if the new requirement for the heading Text is that playwright is awesome, is what should be displayed, then if you modify the copy module, our application will be updated with the new copy.

And if we run our test, our test will continue to function even though we didn't have to make any modifications to our test code. And we can continue down this path of creating shareable modules between our application code and our test. For example, an additional step that you could follow is that create an additional module for the IDs that contains the ID of the counter button.