Playwright Testing: How to Make UI and API Tests 10x Faster with Naeem Malik

[00:00:00] Joe Colantonio Did you know you can unify UI and API automation tests using Playwright? Today, you'll discover how to make your tests 10x faster, more reliable and easy to maintain using this Playwright hybrid approach. And quick note, our guest, Naeem, is not only sharing his deep Playwright expertise, but he's also currently looking for a new remote role in automation testing. If your team is hiring and want someone truly dedicated in experience and someone that's been part of The Guild community for a while, Naeem is definitely someone you should talk to. To hire him and learn more about him use the special link down below. So stick around because this conversation might change the way you use Playwright in your day to day testing. Before we get into it, I have a special announcement. I'm excited to announce that early bird spots for Automation Guild 2026 are now open. And this is a community milestone, our 10th live annual online event, helping software professionals cut flaky tests, shopping their skills and grow the network. And just so you know, early birds get to help shape the conference with timely and important updates about sessions and speakers. You also get priority to reserve your spot before tickets go public and an early bird discount for you and your team, the biggest discount we offer of the year. You don't want to miss it. So definitely register for your early bird tickets using the special link down below.

[00:01:21] Naeem Malik Hi, everyone. Welcome to the show, welcome to the talk/seminar, whatever you want to call it. I am Naeem Malik and I am a senior test automation engineer. There is a lot of interest in Playwright these days and all of us know in the past that we used to have separate libraries for testing APIs and for testing UI. For example, Selenium was a totally different thing and we used to REST Assured. There was another library for C#. I'm forgetting the name, these used to be very like silos. So today, I'm going to speak about how those silos can be somewhat, I would say, how the gap between the silos can be bridged for some projects, not for all projects, because Playwright is mainly focused on UI testing. But it also has some functionalities, some methods and assertions which can be used for API testing and verification. First of all, let us proceed. In the past, we still have the testing test automation pyramid where we have like tests on the bottom and then the integration tests and then the UI tests. And as I said, that the UI tests and the API tests live in separate silos. But with tools like Playwright, there is an attempt going on to basically reduce the distance between the API tests and the UI tests. Playwright provides us basically a means for reducing this fragmentation. And here you can see we used to have like multiple things. Like, for example, there is Postman and if you create your API tests in Postman, you can run those through Newman in your CI/CD pipelines. But again, that's a separate code base to manage. The check-ins are separate and everything else, is separate. Postman makes API testing very easy, I know, and running tests using Newman is also not a big deal. But again, you have to maintain a separate pipeline and you have to maintain a separate code base and so on and so forth. And when the tests, like tests suite in Postman grows large, it can be a challenge to handle. When we are using multiple tools, of course, the complexity of the project is increased. This is where Playwright's unique architecture comes into play. First of all, we know that other than the UI things, like, for example, we had the out of process execution model and then like low level browser interaction. These are, I know, Cypress also has those and Selenium was also pretty good in this respect. But direct HTTP requests were something which were not present in Selenium. Those are, I know that there are libraries available in JavaScript and Node.js, which can be used for calling APIs directly. For example, I would say, like, there is Axios library and there is nothing unique that Playwright is doing here. First of all, let me clarify, Playwright is not doing anything unique here. But the only thing is that it provides us an opportunity for simpler API tests and for creating test data using the same code base. I'm not saying that Playwright can basically be used for like larger API testing projects, but for smaller API testing projects we have direct HTTP requests built in and we can use those without the page object and through the page object as well in Playwright. This is basically the basic and the benefit is that, of course, that we get to have like a single library and we can have a single code base. Things are slightly simple. So simplification is very important. Easy maintenance of a code base is also, very important, so in that regard, Playwright is helpful for us. And moving forward here, we have a small quick comparison. Basically, we know that Postman is great for manual API testing, but the tests you write in Playwright, you create in Postman, if you create some tests in Postman. You cannot include any UI testing code in there basically, not like the first class support. You cannot mix your Postman API calls with the UI, UI tests or UI operations. And then there is REST Assured, we nowadays basically the undisputed champion in the API testing, but we know that you will have to have a separate framework for UI and a separate framework for APIs. This is the challenge which basically causes fragmentation in your test code base. And then we have basically a Playwright which provides us opportunities to unify the UI testing and API testing. Using TypeScript or JavaScript in or even C# or Python under one basically code base. And yes, I believe Java support is also available for Playwright. So we have a single language and we have a consistent API and reporting as well. We also have this detailed comparison, which we can ponder on basically. For example, as I said that we can combine API testing and UI testing in a single code base through a single library using Playwright. But in case of Postman, we have to keep them basically API tests stay separate and UI tests stay separate because we cannot bring them together using Playwright, using Postman. And then again, there is rest assured, which is a completely different paradigm lives separately. It's a separate thing. And the key differentiator here is basically that Playwright allows us to seamlessly integrate UI tests and API tests. While Postman is user friendly, it has got a GUI, which we can use for like developing APIs and like testing as we go. Playwright does not provide any such functionality related to APIs. The REST assured also does not provide any such functionality. So we don't have a REST Assured UI, which could basically use to generate tests. Postman is better in this regard, at least. And then there is language support. Playwright supports multiple languages like there is JavaScript, TypeScript, there's also Python, Java and .NET. Playwright has got language support for multiple languages, which means you can basically use these functionalities in multiple languages. You're not limited to only one language which is not the case for basically REST Assured where we get Java and Groovy. And for Postman, we have only JavaScript. Moving forward, CI/CD integration for basically Playwright is good. You got templates for GitHub actions and Jenkins and GitLab and so on and so forth. In fact, when we are creating a new project in Playwright, it asks us whether if we want to basically create a GitHub actions workflow or YAML file, a GitHub actions file, and we can create a GitHub Actions file right there and then. And it is very easy to run your automation Playwright based automation script using GitHub actions. And then for Postman, if you want to run your tests on CI/CD, for PostMan, you'll need to have Newman installed, which is not a very big deal, of course, you can include it in the pipeline and it will run seamlessly. And then there is Java and Groovy, and then we have REST Assured, of course, we have like very strong CI/CD integration with the Java ecosystem, of course. There's Jenkins and so on and so forth. There is support for, of course JUnit is separate, but a lot of people. People generally use TestNG or JUnit with their Java based unit tests, which are written in REST Assured. So all of the reporting, standard reporting of JUnits, for example, is present in case of Java. And then, well, there is a small overhead when it comes to Playwright. And I am going to speak about it later on. There is a slide about pros and cons of Playwright as well. And I will not skip the cons, of course. And then we have the learning curve. You see, in case of Playwright, there is the learning curve for non-developers can be slightly, curvy, slightly steep, I would say, because the syntax is like peculiar. I would see the syntax is not like very beautiful. For example, here, if you see this could be a lot of a lot a jargon for a new person for a non-developer, like there is a semicolon, there are commas and there are double quotes and so on and so on. And there is a lambda function always. Moving forward, basically, there is a learning curve for people who don't have any coding experience when it comes to Playwright. For Postman, of course, it is mostly like Postman has got a very nice, a very excellent user interface, which we can use for creating API tests. And then basically those tests can be run using Newman on CI/CD. So that is not at all a problem. And for REST Assured, again, there is a learning curve. You need to know Java if you want to use REST Assured. If you want to do your API testing with REST Assured, you will need to now Java. And in the end, the slide says that Playwright is ideal for teams who are seeking a single scalable solution to test the entire application from back-end logic to front end user experience. And also, I would like to add here if you want to create your data quickly using the APIs. If you want to create some test data quickly using APIs, you can use Playwright. In case of Postman, you should use it. If you have a team that needs mostly visual collaboration tool for API development, it is not for like very hardcore coders. And again, REST Assured has got its own basically world where we have basically it's the Java centric thing. And we need to have basically it is again for Developers. This was the crux of this slide. And then there are some bunch of pros. Pros say that, as I have said so many times in this talk that we can use Playwright for unifying the UI testing and API testing. And it needs eliminates the need for multiple tools and there is seamless integration with CI/CD, although it is heavy because of the browser binaries which are included with Playwright and data flow and business logic can be validated very easily using Playwright. And here are the cons. For example, we already spoke that I already said that there is no UI support. If you want to create your API tests, if you want to like play with the APIs using a user interface, no UI is available in case of Postman, in case of Playwright for Postman. We have a UI for REST Assured, we don't have UI again. So Playwright does not have a UI. For like early adopters and you will have to install the browser binaries no matter what you do. And those are slightly heavy. If we are like running our tests in CI/CD, we are creating new machines for our runs or we are setting up new agents. We'll have to basically download 100MB or 150MB of data every time, like it or not. And that it also makes it unsuitable for just API tests. Because API tests not need the browser binaries. Browser binaries are important for UI tests. And yeah, the API testing, tooling and reporting is not very helpful in case of Playwright. If you are making simple assertions, you will be able to basically see what's going wrong. But for complex scenarios, the error messages shown by the Playwright reporting are not very helpful. And then there is basically the last point that which I said earlier that Playwright API testing functionality is useful for simple projects, but it is not very useful or it is not great for large scale API only testing projects. Because of course, we have to download the browser binaries so if we're running them every time will be slightly costly and so on and so on. And then the reporting is not that great in case of the Playwright tests. The Playwright test framework does not provide very good reporting for API testing. The conclusion, so far conclusion is that simple API testing in smaller projects can be done with Playwright. But if you have deep and API only testing, we should use specialized API testing tools like Axios, Jest, Chai, or REST Assured with Java, XUnit or NUnit, depends on your preference. And it is possible to have basically a single config file where we can save the base URL. We can save the storage State as I talked earlier, page storage state, which can be basically reused for logins later on. And Playwright test also has got support for parallel testing and Playwright library provides us with this object, API request context. We can use API request context to make all the basic calls related to API, all the basically HTTP calls like the get call, the post call, the put call, the patch and the delete. All of these are exposed as methods on basically Playwright page object and Playwright request object.

[00:17:31] Naeem Malik Here is a demo without any forewarning. Here I have used basically you can see multiple tests. For example, the first one is yes, deck of cards. This one has stayed consistent over the years. I decided to use it for this demo. So in case of deck of card, we can see that the first method, the first test method here is using just the request object. It does not have a page object. It is going with the request object only. We can use it. And in the second one, I have the page object and the request of that as well. Here you can see that it is very simple to call page.request.get. We can use page.request.post in a similar fashion. And here you can see query parameters are being passed and data is being returned. So all of these techniques can be used basically for different HTTP operations and Playwright provides us different expects or different asserts. These, for example, here we have, if I open deck of card, have I opened it here or not? You will be able to see that the response specification here has got, for example, if we call this endpoint, we get the success, whether it was successful or not, the deck ID, the shuffle is true or not and the remaining cards. And we can perform basically assertions on these values using the expects and basically a combination of the assertion and the evaluator. This is how basically we can Playwright for calling different HTTP methods. And other than that, we have Playwright config.ts This contains a variety of configurations like test timeouts, the base URL and so on and so forth. I tried to configure the base url, but it did not behave properly. So I am not clear about that. So I'm sorry I won't be showing that. But overall, all of these things are basically helpful. They make our lives easier. So we can create some data using the before and after. Using the Before, all are Before, each hook of Playwright as well. We can call our APIs and we can generate our data. If somebody wants to see these tests running, we can run these and I can also show you what does it mean when a test is failing? How does it behave? So this was really quick. We have all of these basically. Data showing on the console related to the different like statuses. For example, I have printed on the console over here. We can use console.log to print various pieces of information returned by an API call. For example we have response.status over here and then all the JSON returned by the response can be present, can be seen using the response.json method call. And all of it can be printed using simple console.log. And I would also like to show you what happens if an API call is failing. For example, get changeable new if something else over here and in this case, this test is going to fail and this is going to establish the point that the reporting for API failures is not really that great. For example, here you see. This is showing, it says that this test ran in Chromium. API tests are independent of Chromium. So here you see it says expected path for this and received was something else. And this caused a problem. If you have like any other API testing tool in place, they would show you more details about it. What went wrong and where it went wrong. Over here, you don't get a lot of useful information about the test failures. This is one more point. Other than that, let's get back to the slides. This is a code which I showed you earlier, but basically we can use the Playwright expect methods to verify different responses. These are like blocking basically simple asserts. In Playwright, we have expect instead of assert. Generally, we use assert in NUnit or JUnit or XUnit. But here we have the expect method call. And this is how we can check whether the response was in the range of 200 to 299 or not. The method expect response to be Ok, checks whether the response was in the range of Ok HTTP codes. Then we have another slide which says that you can combine the power of API and UI in one code base, which cannot be done using Postman or REST Assured. So this is where Playwright can be helpful for us. Although it is possible to cobble together a bunch of libraries inside your test project, and you can still get the same effect. But this is just a strong point of Playwright. And the tests are speedy generally, and we can speed up our tests if we set up the test data via APIs or if we setup the test data and save the test data in the page state as I showed earlier. And then we perform the actions using the UI and then we can verify using the UI or if we like want to verify some data in the back end, we don't need to authenticate separately. For the API, for example, if you create a test, if you sign in from the for example. If you have signed in earlier and you have all the page state data and it also includes the authentication token, the bearer token, you can simply pass the same bearer token over to your API and it will be able to retrieve data. Your tests will be able to retrieve data from the APIs directly. It is also possible leverage the Playwright functionality and combine it with API tests. You can basically use the verification token. You can start at a Playwright test and then use the authentication token for basically getting data, reading data from the APIs. I have not created any example for this demo where we combine both, but this is a very good idea. I should have gotten it. But is there a way to build a helper to build complex validation based on the response from the APIs? We can, of course, cobble together, but the foundational problem is that the Playwright test. The playwright test framework does not have a great support or a great reporting support for errors related to APIs. That will be a problem. We can cobble together something, but that would be a problem. But I should have created an example. All of this code are related to this demo is present on the GitHub in a repo. I will try to add some examples where we combine APIs and UI. I will try to do that later. That's a very good idea. Thanks for suggesting. So are we running out of time?

[00:26:09] Joe Colantonio No, we have 20 minutes, 25 minutes.

[00:26:14] Naeem Malik Yeah, that's great. That's great, and yeah, we can also specify API headers, default API headers in our configuration file using the configuration items shown on the screen. But there is a small problem. If you specify these headers in the configuration file, they will be used for both browser UI calls and for API calls as well. There are other techniques to pass headers from to your API calls if you want to modify them in your Playwright tests. But this is one technique. But this is not like very useful technique because, of course, it is going to mess with your UI tests as well. This is one thing. And this was pretty much all of the material which I had prepared for today. And if you have any questions, please feel free to ask.

[00:27:07] Joe Colantonio Thanks again, Naeem for your automation awesomeness. For links of everything of value we covered in this episode, head on over to testguild.com/A562. And while you're there, make sure to check out all our links and especially register for that early bird using that link down below. And as always, test everything and keep the good. Cheers.