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

## 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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753248738517/e0a5e601-747e-49c7-8b4b-bcb2ce486ae7.jpeg align="center")

## The Two Sides of an Application

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753248805276/9f4eebc8-6cf1-4262-8a61-846046d44965.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753248899546/a640a2f7-dbd9-4cc0-8fa0-63445d1a4c08.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753249045505/39c25adf-b6f3-4291-a239-7a77a204b855.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753249613432/71186cdd-e793-4694-864e-694788d36431.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753250443650/6967931c-5fbe-464f-a3a5-c67dce932684.jpeg align="center")

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

## API Testing

### API Theory

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753251011395/43a2cdb2-aad1-4f9a-a8dc-4ef5c10f4849.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753251296733/8ab73f3f-acef-42c3-a766-dc15ed4b6338.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753252271362/6aaf0710-010b-4be2-9fbb-ae067d8ebc4f.jpeg align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753252355203/a25c995f-1995-4c91-bd19-561ec34cc6c7.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753252448127/6d65908d-f0c7-4053-8eb8-c30c2ee4b20e.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753252579181/b81c8488-a2c0-45b3-911e-f6b83fa2961d.jpeg align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753252710918/e540fc1b-bf9a-4e63-ab89-5366ade912be.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753252822475/9d4d7787-1367-40f7-a6b4-ee66fd183797.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753253152415/bb333659-efcb-4c27-a767-ac0fdfd30cfd.jpeg align="center")

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:

1. The Materials - [GitHub Link](https://github.com/idavidov13/SoftUni-PW-API-Framework-Materials)
    
2. [IDE - Cursor (Windsurf, VS Code)](https://github.com/idavidov13/SoftUni-PW-API-Framework-Materials)
    
3. [Application Under Test (AUT](https://github.com/idavidov13/SoftUni-PW-API-Framework-Materials)) - [Demo App](https://conduit.bondaracademy.com/)
    
4. The Final Repo - [GitHub Link](https://github.com/idavidov13/SoftUni-PW-API-Framework-25.08.2025)
    

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)

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753257269794/ffc86a0b-f366-4062-8df3-90ab806cc960.jpeg align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753257391322/7b6a1f3d-abbf-42d5-ab37-c089cd25155f.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753257433263/24ceb977-03df-4820-8190-cbf1114717fa.png align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753257672562/035e95f7-44a5-40f6-bb6f-da6e5a06d3ca.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753257974649/6f7ed687-91a8-425b-960f-0bd0811fe393.jpeg align="center")

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753258101229/a9252ed4-9cd0-4c6f-b4ca-0a2a3826447c.jpeg align="center")

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](https://www.youtube.com/watch?v=ZcumDI0eQIo&ab_channel=SoftwareUniversity%28SoftUni%29). Just keep in mind that it is in Bulgarian.