Playwright Framework: REST API Testing Session

Session Notes

Below, you can find my notes and presentation, I used to prepare for my first Live Session. Hope you can find them helpful, since the lecture was held in Bulgarian.

Greetings

Hey friends! It's awesome to be here at SoftUni. Thanks for joining. We're going to talk about something I'm really passionate about today - building testing frameworks that people actually want to use.

The audience is from all levels, but my goal here isn't a boring lecture. I want to start a conversation and show you just how simple and elegant testing can be when you have the right tools and the right mindset.

Agenda

The Two Sides of an Application

Alright, let's start with the absolute basics. Every modern application you use, from a social media app to your online banking, has two main parts.

First, you've got the Front-End. That's the part you see and interact with. The buttons, the forms, the pretty charts. It’s the user interface.

Then, you've got the Back-End. This is the engine. The brain. It's where the real work happens—all the business logic, the calculations, talking to the database.

Communication Between the Two Sides

So how do they talk to each other? They use an API—an Application Programming Interface.

Based on user actions, the front-end makes a request, sends it to the back-end via API, then the back-end does the work and sends a response to the front-end again via API. Lastly, the front-end processes the response and visualize it to the customer.

Where and What Do The Bugs Hide?

Front-End vs Back-End Bug Distribution

The data can vary significatly due to different factors such as complexity, team maturity, domain, etc. but we can safely assume that the distribution is somewhere in the range of 70% FE vs 30% BE. And it is logical, because there is no such factors as User Environment, Front-End tech Stack, Interactive Natature of the FE, in the BE.

The Nature of Bugs: A Volume vs. Severity Profile

Despite the fact that most bugs are in the FE, the sevier ones can be found in the BE. And it makes sense! That’s where the complexity is. That's where data gets validated, where security is handled, where the core business rules are executed. A bug in the UI is an inconvenience. A bug in the API can be a catastrophe—data corruption, security vulnerabilities, you name it.

The above absolutely NOT means that UI bugs are not important - we all can agree that if the user is not satisfied by his experience, most probably he won’t return to our app.

The Escalating Cost of Bug Remediation by Development Stage

It's no secret that the later a bug is found, the more costly the remediation actions will be.

API Testing

API Theory

REST API communication is a Stateless Client-Server Communication, which means, every single request should contain the whole context.

These are the main components of an REST API Request and Response.

We will begin with these from the Request. Endpoint is a combination of Base Url and the Path of the resource, you are trying to interact with.

These are the most common Methods, used in REST API, responsible for CRUD (Create, Read, Update, Delete) operations.

The requst headers and body are used to specify what actions the User wants to perform - autorization and data.

The Status Code of the Response is always presented, and it can be used as a clear sign of the outcome. You can see on the image how the statuses are categorized.

In addition to the Response Status Code, you can find Response Headers, and optionally - Response Body. This is the message Server delivers to the Client.

The Importance

With testing the APIs, we can verify that it works functionally, it is fully integrated in the system, it covers the security standarts, that are set and that the performance is acceptable.

The Power of a Unified Tool

Okay, so when you hear 'Playwright', you probably think of UI testing. Automating a browser, clicking buttons, filling forms... and you're right, it is absolutely world-class at that.

But its real power, the thing that changes the game, is using it as a single, unified tool for your entire testing suite. UI and API, together.

Why is that such a big deal? Four reasons.

Reliability and Speed

First, Reliability and Speed. Playwright enhances test reliability by incorporating auto-waiting mechanisms that ensure actions are only performed when elements are stable, which drastically reduces flaky failures common in other frameworks. By leveraging a modern architecture that allows for test parallelization across multiple browser contexts, Playwright achieves remarkable execution speed, significantly cutting down the time for running extensive regression suites.

CI/CD Simplification

Second, CI/CD Simplification. If you use different tools for front-end and back-end testing, your deployment pipeline gets complicated. Two sets of dependencies, two test runners, two reporting formats. With Playwright for everything, it's one process. One command to run all your tests. One beautiful, consolidated report. Your pipeline becomes simpler, faster, and way easier to maintain.

Seamless End-to-End Testing

Third, Seamless End-to-End Testing. This is where it gets really cool. Imagine a single test that does this

Step 1: Create a new user by sending a POST request directly to your API. It's fast and reliable.
Step 2: In the very next line of code, use the browser to log in as that new user through the UI.
Step 3: Verify their dashboard looks correct.

Developer Experience

Last, but not least, this is for those of you who've built testing frameworks before... we're going to solve the biggest challenge of all: Developer Experience, or DX.

It's not enough for a framework to just work. It has to be a joy to use. Today, we're going to build a custom API fixture that makes writing API tests almost effortless. It will be clean, readable, and type-safe. This is the secret to getting your whole team to write more, better tests.

Developing Playwright Framework for REST API Testing

Finally, we can start with the “interesting” part of the session. As prerequisites. you will need:

So, using Playwright to make a simple API call is easy. You can find that in the docs. But that doesn't scale to a real project with dozens of developers and thousands of tests.

To do this right, you need a scalable and maintainable framework. And the whole point of a good framework is to make the right way to write tests the easy way.

Developer Experience (DX)

Let’s start from improving DX, cuz we can do it before even we initialized our Playwright framework. You can see on the slide why it is important and how can we improve it.

Next task is to build an Abstraction Layer for our API calls.

On the left hand side you can see our plaun-function.ts - a function that receives input parameters and outputs only what we need. And it is doing it in unified way.

On the right hand side you can see our types.ts - a file with all types, which are needed to make TypeScript happy.

The logical next step is to talk about Fixtures in Playwright and how powerful they are.

Implementing Fixtures is quite easy - on the left hand side you can see how we extend the test base with our custom fixture.

On the right hand side it is an optional step, which I am showing, because it is used to merge all separate Custom Fixtures in one.

Last, but not least, we should cover Zod - TypeScript-first validation library.

Live Demostration how the Framework is Developed with Examples

After cloning the initial repo, there is a step-by-step checklist in README.md, that will guide you in the process. If you want, you can jump straight into the final code.

Closing Notes

I really hope that the following notes are helpful to you. As always, if there are any question, please let me know in LinkedIn. I will gladly try to answer to them.

You can find the recording of the session in YouTube. Just keep in mind that it is in Bulgarian.

My First Live Session - Developing Playwright Framework for REST API Testing