Playwright Test is a modern test runner from Microsoft, and while it is famous for browser automation, it includes a genuine API testing client. In TypeScript you get a request fixture that sends HTTP calls and an expect that reads naturally. The same project can hold browser tests and API tests under one runner, one config and one report, which is why many teams reach for it.
How it works
Each test receives a request fixture and uses it to call the API. You assert on the status and on the parsed body with Playwright's expect. Here is the login test:
test('should return access token on successful login', async ({ request }) => {
const payload = {
email: '[email protected]',
password: 'welcome01',
};
const response = await request.post(`/users/login`, { data: payload });
expect(response.status()).toBe(200);
const responseBody = await response.json();
expect(responseBody).toHaveProperty('access_token');
});
The base URL is set in playwright.config.ts, so tests use short paths. A protected test uses a beforeAll hook to log in and keep the token, then sends it as a Bearer header. The config in this project runs across three browser projects, chromium, firefox and webkit, and you launch the suite with npx playwright test.
Benefits
The developer experience is a highlight. Tests are plain async and await TypeScript, the API is small and consistent, and the built in reporter, tracing and retries are excellent. Running in full parallel makes the suite fast, and having browser and API tests share a config removes a lot of duplication. Playwright is actively developed and well documented, so help is easy to find.
Downsides
For a pure API suite, running the same tests across three browser engines adds time without adding value, since the HTTP client does not depend on the browser. That multiplication is worth trimming if you are only testing endpoints. Like the browser tools in general, Playwright is a large dependency to install for HTTP only work, and you still parse and assert on JSON yourself rather than through a dedicated API matcher. It is a strong choice when API tests share a home with browser tests.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-ts-playwright tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used across this series. The base URL is set in playwright.config.ts.
Three specs are covered. A brands spec calls GET /brands and checks for status 200 with at least two entries. A login spec posts credentials to /users/login and asserts the response has an access_token. A protected invoices spec logs in during a beforeAll hook, sends the Bearer token to GET /invoices, and checks the returned list. A GitHub Actions workflow runs npx playwright test with retries on CI. The scenarios match the Cypress and the Jest with Supertest examples, so the three TypeScript approaches can be compared directly.