The Definitive Guide to API Test Automation With Playwright: Introduction
I have had a few folks ask if it's possible to do API testing with Playwright, the short answer YES! With this next series of posts I will walk through all the ins and outs of utilizing Playwright for all your API Testing needs. This will be the first article in a series of many. I'll plan to keep this page and the following posts up to date with the latest information.
First off you may be wondering why in the world would you want to build API Tests in a tool such as Playwright that is built for UI testing. Well for me towards the end of 2021, I did a brief proof of concept for our UI end to end tests and selected Playwright as the tool of choice. After deciding that I took another week and did a proof of concept with different tools to select a tool for my API testing needs. The application our team was building was built API first for developers to integrate to our platform with.
I chose this as criteria as all of our production code was written in TypeScript, and I wanted our development team able to jump in and add/update tests if business logic changes.
- I wanted to be able to easily make API calls at any time from anywhere, specifically to create test data as needed.
- I wanted the ability to get details out of the response body from within a test run, and save values to variables.
- I wanted the ability if a automated check failed to see the response headers and response body of the request that was made for quick debugging.
- I wanted full control over the full url when making API calls (I have scenarios where I may need to use a different baseURL in the middle of a test.
I evaluated Frisby.js , PactumJS, SuperTest, and Playwright. Side note I also evaluated Postman, which we were using at the time for a set of smoke tests that could run after a build. For the level of depth I wanted to go I decided that Postman, though a great tool for exploratory testing, would have been too big of a lift to manage a full regression suite of tests.
Going through the week of testing and learning, I found each of these tools all easy to get started with but through the proof of concept and decision making process, Playwright was the winner for me. One thing that Playwright does really well is allow you to use object oriented programming within your API tests. I am able to assign a variable to the GET,PUT,POST,DELETE, and then use that variable to get information about the response that the server was given. This allowed me to get making 5-30 assertions on an API response without a crazy amount of chaining. One other positive was to reduce cognitive load on the contributors. Only having to learn 1 framework between UI and API automation means an overall quicker ramp up time for new contributors.
As I work through each article they will have examples that will be available at the below repository.
As each article is released I will update this page, linking to each completed article.
Part 1 - Basics of API Testing GET Request With and Without Authorization
Part 2 - Adding More In-Depth Checks
Part 3 - Debugging API Tests With VS Code
Part 4 - Handling Headers and Auth
Part 5 - Calculating API Endpoint Coverage
Part 6 - Creating a DataFactory to Manage Test Data
Part 7 - Creating Helper Functions for Common tasks
Part 8 - Using beforeAll and beforeEach and Organizing the Tests
Part 9 - Validating JSON Schema
Part 10 - API Testing With Playwright Best Practices
Part 11 - Creating Custom Assertions Through Extending Expect
Thanks for reading! If you found this helpful, reach out and let me know on LinkedIn or consider buying me a cup of coffee. If you want more content delivered to you in your inbox subscribe below.