Wrap Up | Bondar Academy
Course: Playwright API Testing with TypeScript
Module: API Testing Basics
Instructor: Artem Bondar
Lesson Summary
Summary of API Testing with Playwright In this lesson, we covered the fundamentals of making API requests using Playwright and Postman. Key topics included: Types of API requests: GET , POST , PUT , and DELETE . Reading values from APIs for future calls. Running tests and making assertions. However, a challenge arises when writing tests with Playwright for API testing. Despite being a robust framework for UI testing, Playwright is not optimized for API testing, leading to: Complexity: Tests can become lengthy and difficult to read, with nearly 120 lines of code for just four tests. Redundancy: Repeated calls to extract JSON data and validate status codes make the code cumbersome. Maintenance Issues: The busy appearance of the code can complicate debugging and future modifications. Examples of inefficiencies include: Requiring multiple calls to extract JSON data from responses. Complex syntax for validating status codes, such as expect(newArticleResponse.status).toEqual(201) . To address these issues, the next section will focus on developing a custom framework based on Playwright. This framework will enhance readability, simplify scripting, and introduce features like schema validation and custom assertions, leveraging the flexibility of Node.js and TypeScript . Stay tuned for the upcoming module, where we will implement these improvements!
Video Transcript
All right guys, so let's make a quick section wrap up to summarize what we have learned so far. So you're already familiar with all types of API requests, how to make API requests in the Postman, how to perform those requests in Playwright, post, put, get, and delete, how to read the values from the APIs and reuse those values for the future calls, how to run those tests, and how to make the assertion. So, so far you know all the basic operations with the framework and about API to actually write API tests. But there is a catch. Let me show you something. So when we were writing our test, I think you might notice quickly how kind of complicated and busy our test became. So we wrote just four simple tests, right? And we already have, look, how many? Almost 120 lines of code. And when you look at the test and trying to kind of looking into that, you understand, okay, this is my step one, step two, step three. It's not really easy to grasp the entire picture about what your test is doing and where are the steps. So the overall test looks kind of busy, right? And this is because the Playwright is just not optimized for API testing. Unfortunately, Playwright shines in UI testing. This is a great framework for UI testing, but for API testing, unfortunately, it is not. So if you will write your test like that, well, you can do it. But down the road, it will be hard to maintain, hard to debug, and so on. And the framework has kind of a bunch of redundancies implemented out of the box. And let me show you some of the examples. For example, when you make a request, we always need to make a call for this JSON object to extract the JSON body. So every single time we make a request, we need to call this JSON, JSON, JSON. Wouldn't it be much nicer if the framework returned the JSON as a kind of default behavior, right? So we don't need to make this step. And to make, for example, status code, first, we need to call the original object and calling method status. But for the JSON object, we need to call the JSON method. And to manage this and not get confused, we need to create every time a different name. For example, new article response, new article response JSON, update article response, update article response JSON. And all those extra steps, extra lines create kind of busy look of the code. And another example, how we validate the status code. So to make such a simple operation as a status code validation, that should be actually a kind of a default behavior for the test framework. Because every time you make a request, you have to validate status code as a confirmation that your request was successful. That's the first thing that you always have to do. And look, to make this such a simple operation, we need to call such as expect new article response dot status to equal 201. Kind of too much, isn't it? Shouldn't this done be somehow easier? And also the request itself. So look at this. So this is their request body. This is the headers. And this entire section, it looks kind of big, messy and hard to read. Well, we cannot blame Playwright. It's as I said, it was not optimized for scripting API test. It does its job very well, making those requests very stable and so on. But just the scripting experience is not that nice. So in the next section, we will work on our custom framework based on the Playwright. And the good news that Playwright is very flexible framework and we have a power of Node.js and TypeScript. So we technically can build whatever we want. So in the next section, we will build our custom framework, optimizing all those things and making our test significantly more readable and easier to script, easier to debug and even add some new features and new functions such as schema validation and custom assertions. All right. So I hope you are excited about what is coming. I hope you like the stuff that I'm about to show you and see you in the next module.