Playwright vs axios

@rajucheers I m using Axios too . With Axios ans State mechanism my tests so speed and more manageable

I've got a suite of 1400+ api tests using only playwright api methods, have no issues, suite is fast, the built in test runner and reports with trace files make debugging easy. I haven't used axios directly but I'm pretty sure that's whats being used underneath the playwright implementation.

interesting thoughts

@yusufozt. , what is State mechanism?

@rajucheers Saving axios response to state but you can also run states with Playwright api For e.g saving responses to States and calling them in tests

export const ReportsState = { //API createdDashboardId: {} as string, createdDashboardTitle: {} as string, createdWidgetName:{} as string,

//E2E
createdFakeWidgetName: {} as string,
createdFakeDashboardName: {} as string,
updatedFakeWidgetName: {} as string,
fakeQuadrantNumber: {} as any

}

By the way axios interceptors are useful

We use axios within our playwright framework to do our api handling / calls. I've built out two similar services that utilize axios vs playwright api tools and found that axios provides a little more speed and better async handling for some of our specific api endpoints that require multiple steps.

Ok

I used both axios and playwright. One disadvantage that I see with playwrifght. If I use another context to api to add the auth another tracer is added to html reporter.

For easier troubleshooting I'd recommend Playwright's APIRequestContext (request or page.request) since its API requests and responses are included in Playwright's trace files. I don't think that's the case with axios. https://playwright.dev/docs/trace-viewer-intro

ok

Hmm, it seems that Plawright has its own fetch implementation: https://github.com/microsoft/playwright/blob/2f4acbb001f5e057de243fedc075b37bcc7719a7/packages/playwright-core/src/server/fetch.ts

The main benefit for me is how easy we can create AXIOS API clients based on OpenApi documentation using swagger-typescript-api I have used it in two projects and it has been easy to maintain and develop, you can check this examples: https://github.com/pajdekPL/pw_structure/

With PW and TS we can probably at least use typing: https://openapi-ts.dev/introduction

Axios API calls won't get included into the Playwright trace files. The APIRequestContext (request / page.request) API calls will get included.

The trace files and trace viewer are incredibly useful tools for troubleshooting, and it's a waste to have to miss that.

I would advocate for using Playwright's built-in APIRequestContext any day. https://playwright.dev/docs/trace-viewer-intro

Regarding the difference with generating API clients: Probably someone in the community should write OpenAPI client generators for Playwright, then that difference is gone.

I've been dabbling with this, but no where ready, even have a postman collection reader... 🙂 All part of a large tool set i've been working on.

Axios is a good tool, we use it in our performance testing since it is lighter weight than using the Playwright framework. I also use it in Cypress to perform API calls during setup to verify the environment. (I thought of using Playwright, but found that would be like using Puppeteer in Cypress... Oh wait...🫠 ). I have not found a reason not to use Playwright APIRequestContext, I find that it is cleaner and performs well for my testing needs in Playwright. Another nice thing is that I have less NPM packages to manage since it is bundled in the base framework. Again, Axios might be required if there is a niche requirement, but would veer towards APIRequestContext usage.

just wondering whether anyone has evaluated the performance between the 2?

currently the project at work is using axios but there are many abstractions which i feel mighy have slow the projecy.but this shift would require huge efforts

I would write my own api's routines that proxy the call to one or the other, very common and typical for any routines that interface with external API. Ever maintain MS-DOS, WindoZe, Unix, OS/2 while more often i was doing this in C/C++, we'd use "#if defined OS_VERSION" conditionals to choose which routine actually used in our wrapper functions.. In general would assert a generalized API library like Axios has gone through a few rounds of performance testing. Then again might be a great example of trying to optimized something way too soon? Would assert Uncle Bob wouldn't be a fan, but what does he know? 🙂