API Automation testing with Cypress and Playwright.

API Automation testing with Cypress and Playwright.


We are going to compare one scenario using two different frameworks: Cypress and Playwright.

For our experiment, I will be using this site: https://conduit.bondaracademy.com/.


Let's imagine we have the following test case:

  1. Create a new article.
  2. Verify the post appears in the feed.
  3. Verify the post is not visible to a logged-out user in the 'Global Feed'.
  4. Verify the post is visible through an API call if we know the title name (this might be an issue, but it's an additional step for our case).


Here is the code for Cypress (with Cypress API plugin) :

Article content
We could probably also add an 'after each' hook for deleting our new post.

A few interesting details:

  • I'm using a method with different permissions, essentially utilizing a simple if-else statement:

Article content
We could create two different methods or optimize this function, but this is just an example of how Cypress can work with if-else statements.

  • Optimized version for this method could look like this :

Article content

  • Global hook that runs before the test suite starts and takes the token:

Article content
We can use it in our e2e file inside the support folder.

You can find the full repo here : https://github.com/EvgeniiDolzhenko/cypress-conduit-api .

It's designed for a specific user, but feel free to run it on your end, as the 'cypress.env.json' file with credentials is available for public use. You might discover some more interesting examples.


Let's compare Playwright's code using the same test scenario:

Article content
Code looks more compact, doesn't it?

I would like to highlight some details:

  • Using fixtures and pages. Instead of creating a new instance, we can include them directly in our test or describe block from our special test.ts file: async({ articlePage }). Additionally, there's no need to create a new instance in our spec file. Instead, we only need to import our test and expect from our test.ts file: import { test, expect } from '../../common/test'.

Here is the test.ts file:

Article content
It's easier to maintain our pages from a single place.

  • Another important aspect here is to create a global-setup file for our global hook, which allows us to fetch the token before execution and use it as needed:

Article content
Playwright has a few other options for storing tokens or cookies, but I decided to use this method.

Article content

  • I applied the same logic to my method and optimized it:

Article content

Full repo is here : https://github.com/EvgeniiDolzhenko/playwright-conduit-api-ui (still in progress) .


Conclusion:

Both options look interesting to me. My opinion is that it's easier to set up a global hook in Cypress, and the Cypress API plugin allows you to monitor everything that's happening in open mode, which I find to be a significant advantage for Cypress. I hope Playwright will implement something similar in the future.

On the other hand, Playwright offers an amazing fixture feature that allows you to centralize your pages in one place, which is definitely a great advantage. Additionally, the await/async logic in Playwright seems more readable and compact compared to Cypress (.its, .then, etc.).

What do you think? Which option did you prefer more?


P.S.

Perhaps some things could have been done differently, and there is always room for improvement, but I believe some of you will find this information helpful.

Thank you.




Eugene Dolzhenko , after 9mo of your article , there is now available a Playwright api plugin to see results in the console UI, Trace viewer, and HTML report 🙂 https://github.com/sclavijosuero/pw-api-plugin

Like
Reply

Amazing article, loved reading it. Keep up

Like
Reply

Exciting article Eugene! I feel like Cypress is a more mature solution at the moment, Playwright however can boast of some features that Cypress currently does not have. In general Playwright looks very promising.

To view or add a comment, sign in

More articles by Eugene Dolzhenko

Others also viewed

Explore content categories