Jest with Supertest is a common pairing for API testing in the JavaScript and TypeScript world. Jest is the test runner and assertion library that many front end and Node teams already use, and Supertest is a small library for making HTTP requests and asserting on the response. Put them together and you have a fast, lightweight way to test an API in the same language and the same runner as the rest of a Node project.
How it works
Supertest wraps an HTTP client in a fluent interface. You point it at a base URL, call a method and a path, then await the response and assert on it with Jest's expect. There is no browser and no heavy framework in the way:
import request from 'supertest';
describe('Brands API', () => {
const baseUrl = 'https://api.practicesoftwaretesting.com';
it('should retrieve at least two brands', async () => {
const response = await request(baseUrl).get('/brands');
expect(response.status).toBe(200);
const data = response.body;
expect(data.length).toBeGreaterThanOrEqual(2);
});
});
For a protected flow a beforeAll hook logs in, keeps the access_token, and later requests send it as a Bearer header. In this project the tests are TypeScript run through ts-jest, and the base URL is a constant inside each test file. You run the suite with npm test, and an HTML reporter turns the results into a readable page.
Benefits
This stack is light and quick. Jest starts fast, runs tests in parallel and gives clear failure messages, and Supertest keeps the request code short and direct with plain async and await. If your team already writes Jest tests, there is nothing new to learn beyond a small library. It is an excellent fit for testing a Node service, and it drops into any CI pipeline with a single npm command.
Downsides
Because the base URL is a constant in each file rather than shared configuration, moving between environments means touching several files unless you refactor that out. Supertest is deliberately minimal, so it does not offer the JSON path assertions or schema matching that a dedicated API framework provides, and you assert on the parsed body by hand. For very large suites you will want to add your own structure for shared setup and helpers, since the tools give you little of that out of the box.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-ts-jest-supertest tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used across this series.
Three tests are covered. A brands test calls GET /brands and checks for status 200 with at least two entries. A login test posts credentials to /users/login and confirms the access_token. A protected invoices test logs in during a beforeAll hook, sends the Bearer token to GET /invoices, and checks the returned list. A GitHub Actions workflow runs npm test and produces the HTML report. The scenarios match the Cypress and Playwright examples, so you can weigh this lean approach against the two browser based tools on identical ground.