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

In a land of testers far and widely journey, seeking answers, seeking skills, seeking a better way O the Test Kill Animation Testing Podcast Guiding testers with our nation awesomeness. From ancient realms to modern days, they lead the way. Oh, the testicle of Nature Testing Podcast.

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 Naim 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 and experienced and someone that's been part of the Guild community for a while, Naim 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, sharpen their skills and grow their 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 so you don't want to miss it. So definitely register for your early bird tickets using the special link down below.

Hi everyone, welcome to the show. Welcome to the Talk Seminar, whatever you want to call it. I am Naim Akram Malik and I am a senior Test Automation engineer. So there is a lot of interest in Playwright these days and all of us now 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 have rest assured there was another library for C Sharp. I'm forgetting the name, but 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, you know, mainly focused on UI testing, but it also has some functionalities, some methods and assertions which can be used for API testing and verification. So first of all, let us proceed.

In the past we still have the Test Automation Pyramid where We have like, you know, tests on the bottom and then the integration tests and then the UI tests. As I said that the UI test and the API test live in separate silos. But with tools like Playwright, there is an attempt going on to basically reduce the distance between the APA test and the UI test. 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, you know, 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 else you know is separate. Postman makes API testing very easy. I know 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 Test suite into Postman grows large, it can be a challenge to handle. So when we are using multiple tools, of course, the complexity of the project is increased. And 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. The only thing is that it provides us an opportunity for simpler API tests and for creating best test data using the same code base. So 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. So 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 and things are slightly simple. So simplification is very important. Easy maintenance of a code base is also, you know, 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 you Cannot basically the tests you write in Playwright you create in Postman. If you create some tests in Postman, you know you cannot include any UI testing code in there basically and not like with first class support. So you cannot mix your Postman API calls with a ui, UI tests or UI operations. And then there is Rest Assured. We know it is 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. So 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 sharp or Python under one basically code base. And yes, I believe Java support is also available for Playwright. So we have 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 UA testing a single code base through a single library using Playwright. And but in case of Postman, we have to keep them basically API tests stay separate and UA test 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 to 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 assure also does not provide any such functionality. So we don't have a Rest Assured UI which we could basically use to generate tests. So Postman is better in this regard at least. And then there is language support. So Playwright supports multiple languages. Like there is JavaScript, TypeScript, there is also Python, Java and dot net. So 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, you know, we have only JavaScript. So moving forward, CICD 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 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 Postman for Postman. If you want to run your test using on cicd for Postman, you'll need to have Newman installed, which is not a very big deal of course. Just need to. You can include it in the pipeline and it will run seamlessly. But there is this difference. And then there is Java and Groover and then we have in Rest Assured of course we have like very strong CICD integration with the Java ecosystem. Of course there's Jenkins and so on, 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 Junit for example is present in case of Java. And then 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 the 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 a. The learning curve for non developers can be slightly, you know, curvy, slightly steep I would say because the syntax is like peculiar. I would say the syntax is not like very beautiful. For example here, if you see there is a. This could be a lot of jargon for a new person, for a non developer. Like there are, 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. Yeah, so 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, you know, 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 cicd. 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 know 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 backend logic to front end user 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 a Java centric thing and we need to have basically it is again for developers. So 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 cicd, 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, if using a user interface, no UI is available. In case of Playwright for Postman, we have a UI for us to show we don't have UI again, so Playwright does not have a UI for like early adopters. And you'll have to install the browser binaries no matter what you do. And those are slightly heavy. So if we are like running our tests in cicd, we will have to basically and we are creating new machines for our runs or we are setting up new agents. We will have to basically download 100 MB or 150 MB of data every time, like it or not. And 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 which means we 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. So the conclusion so far conclusion is that a simple API testing in smaller projects can be done with Playwright, but if you have deep and API only testing, we should use a specialized API testing tools like Axios, Jest, Chai or rest assured with Java, Xunit or any unit depends on your preference. And then we have 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 yeah, 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 basic HTTP calls like the get call, the post call, the put call, the patch and the delete. So all of these are exposed as methods on the basically Playwright page object and playwright request object. Here is a demo without any forewarning. So here I have used basically you can see multiple tests. For example, the first one is yes, stack of cards. This one has stayed consistent over the years, so 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 object 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 aspects for 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 basically on these values using the expects and basically a combination of the assertion and the valuator. So this is how basically we can use we can use Playwright for calling different HTTP methods.

And other than that we have playwright config config ts. This contains a variety of configurations like test timeouts, the BS URL and so on so forth. I tried to configure the base URL but it did not behave properly. So I'm 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 or 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 you saw, this was really quick. So 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 console 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 you 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, can change a value to 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, so this is showing it says that this test ran in Chromium. Again, 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 tools in place, they would show you more details about it, what went wrong and where it went wrong. So over here you don't get a lot of useful information about the test failures. So this is one more point. And other than that, let's get back to the slides. So this is a code which I showed you earlier, that basically we can use the playwright expect methods to verify different responses. These are like blocking, basically simple asserts. So in Playwright we have expect insert instead of assert. Generally we use assert in N unit or junit or X unit. 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 okay checks whether the response was in the range of okay HTTP codes. And 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 play, right? And the tests are speedy generally. And we can speed up our test if we set up the test data via APIs, or if we set up 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 when we can verify using the UI or if we like want to verify some data in the backend, we don't need to authenticate separately for the APIs. For example, if you create a test, if you have. 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 is. It will be able to retrieve data. Your tests will be able to retrieve data from the APIs directly. So it is also possible to leverage the playwright functionality and combine it with API test using app. 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. Yeah, 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. Chris. Yeah, 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 player test, the playwright test framework does not have a great support or a great reporting support for errors related to APIs. So that will be a problem. So we can cobble together something. But that would be a problem. But I should have created an example. All of this code related to this demo is present on my GitHub. 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. Yeah. So are we running out of time?

No. Yeah, I have a 20 minutes, 25 minutes.

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. So there are other techniques to pass headers from to your API calls if you want to modify them in your Playwright tests. 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. So 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.

Thanks again Naim 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, Seth Arithum. And keep the good Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation, software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.