Creating Reusable API Methods with Playwright Mimicking the Page Object Model

In this video, we'll be taking a look at how to create reusable API methods using Playwright, a powerful tool for automating web browsers. We'll be mimicking the page object model, a design pattern that helps to improve the maintainability and readability of our test code. By the end of this tutorial, you'll have a solid understanding of how to create and use API methods to interact with APIs in a more consistent manner.

Whether you're a beginner looking to get started with automated testing or an experienced developer looking to improve your workflow, this video has something for you. So let's get started!

Check out more great QA content on our website!

Not interested in learning Playwright, but want great test automation. Let us build it for you!

[jeremiahlee]

Hey man I’ve been searching for a break down on using reusable api calls for a few days. This is pretty much exactly what I was looking for. As somebody who been using cypress for a few years now I really like custom api functions to quickly set up an end to end test when required. I’ve been trying to research the benefits of playwright over cypress and this has been my biggest hesitation. Seeing this though makes it much easier to see a path/argument to be made for playwright. Again hugely appreciate your time on this video!

[dixondavis]

Is there a way to get the API response without sending the {request} in constructor? I need an idependent API module that could be called in from any test case or even from a framework's utilities method. As i shall be calling this method from another utilities method, i will not have the {request} context to pass .

[StevenBoutcher]

I wouldn't pass in the response, personally. It feels like too much abstraction.

In my view, the UI equivalent of that would be where the page object has a method checking for an error message that only shows up 1 time in the test suite. You have to check 2 files instead of 1 during debugging if that method fails.

Assertions should live in their raw form in the test file, unless you find yourself using the same batch of assertions for multiple test scenarios.

I'm a fan of templating your requests like you're doing, though. Requests are almost always used more than 1 time with different parameters, so that's hugely helpful.

[numanhanduran]

nice approach. could you share the example repo for this?

[jothiseetha]

Good explanation. Can you share git repo for this project?