Testing and quality

A unit test might call a calculateTotal function with a cart of two items and a discount code, then assert that the result is exactly what it should be. Because it touches no network, database or browser, hundreds of them run in a second or two, so developers run them constantly while working and CI runs them on every change.

Anything that would make a test slow or unpredictable, such as an API call or the current time, is swapped for a mock or a fake. Unit tests form the base of the testing pyramid: many cheap tests at the bottom, fewer integration tests above them and a handful of end-to-end tests at the top. They are good at pinning down logic and edge cases, and weak at proving the whole app works.

Where a unit test isolates one function, an integration test lets real parts talk to each other. It might start the API, send a request to /orders, and check both the response and the row written to a test database. On the frontend, rendering a whole component with Testing Library and clicking through it is a common form.

They catch the bugs that live where parts meet: a wrong column name, a missing header, a validation rule that disagrees with the server. They are slower and need setup (a throwaway database, seeded data, often run in Docker), so most suites have fewer of them than unit tests, focused on the paths that matter most.

An end-to-end test opens the site, signs up with a test account, adds a product to the cart and checks that the order confirmation appears. Because it exercises the frontend, backend, database and outside services together, a passing run is strong evidence that the whole journey works. Playwright and Cypress are the usual tools; Puppeteer suits lighter automation.

They are the slowest and most fragile layer: timing, test data and third-party services can make a test fail now and then for no real reason (a flaky test). Teams keep them to the critical journeys, such as sign-in, checkout and payments, run them against a preview or staging deployment in CI, and use traces, screenshots and videos to debug failures.

Vitest reuses a project's Vite configuration, so TypeScript, JSX, ES modules and path aliases work in tests exactly as they do in the app, with no separate Babel setup. Its describe, it, expect and vi.fn() APIs mirror Jest's, which makes moving an existing suite mostly a matter of changing imports. Watch mode reruns only the tests affected by a change, almost instantly.

It covers unit and component tests with jsdom or happy-dom, snapshots, code coverage through V8 or Istanbul, and type tests. Browser Mode runs tests in a real browser through Playwright or WebdriverIO, for components that depend on real browser behaviour. It also works outside Vite projects, such as plain Node.js libraries, and is maintained by the same community as Vite.

Jest bundles everything in one package: a runner that executes test files in parallel, the expect assertion library, jest.fn() mocks and module mocking, fake timers, snapshot testing and code coverage. Tests usually run in Node.js or in jsdom, a simulated browser, which is how React components are commonly tested with Testing Library.

It came out of Meta (Facebook) and has been looked after by the OpenJS Foundation since 2022. It remains the default in React Native and in many established React and Node.js projects. Its weak spots are modern ones: TypeScript needs a transformer such as ts-jest, Babel or SWC, and native ES module support is still marked experimental, which is a large part of why new Vite projects pick Vitest.

A pytest test is a function whose name starts with test_, and a failing assert shows exactly which values differed. Fixtures supply what tests need, such as a database session or a signed-in client, and clean up afterwards, while @pytest.mark.parametrize runs one test over many inputs. It also runs older unittest-style tests, so projects can switch gradually.

A large plugin ecosystem adds coverage (pytest-cov), parallel runs (pytest-xdist), async tests (pytest-asyncio) and framework helpers such as pytest-django. FastAPI and Django projects commonly pair it with a test client to exercise API routes over HTTP without starting a real server.

Instead of reaching into a component's internal state, Testing Library queries the rendered page by role, label or visible text, for example getByRole('button', { name: 'Pay' }). The user-event package simulates real typing and clicking, and jest-dom adds readable checks such as toBeVisible. Versions exist for React, Vue, Svelte, Angular, plain DOM and React Native.

It is not a test runner: it runs inside Jest or Vitest, usually with jsdom, and Cypress has an adapter, while Playwright's own locators follow the same idea. Because tests find elements the way assistive technology does, they nudge code towards accessible markup, and they survive refactors that do not change what users see.

Playwright drives browsers from code: open a page, click, type, wait for responses and check what appears. Its test runner, Playwright Test, runs tests in parallel across browsers and emulated devices, waits for elements automatically (which cuts down flaky tests), and records traces with screenshots, network logs and a timeline you can step through after a failure.

It was built by the team that created Puppeteer at Google before moving to Microsoft, and it supports JavaScript and TypeScript, Python, Java and .NET. Codegen writes a test while you click through the site, UI mode shows tests running live, and a Playwright MCP server lets AI agents control a browser. Beyond testing, it is widely used for scraping, screenshots and PDFs.

Cypress opens a browser with your app on one side and a log of commands on the other. Commands such as cy.get('button').click() retry automatically until they pass or time out, and time-travel snapshots let you hover over any step to see the page as it was at that moment. Because tests run in the same browser as the app, they can stub network requests and reach into the app's code directly.

It supports Chrome-family browsers, Firefox and Electron, with WebKit support still experimental, and tests are written only in JavaScript or TypeScript. Several tabs in one test are not supported, and visiting several domains needs cy.origin. The app is open source; Cypress Cloud is a paid service that records runs, spreads them across CI machines and replays failures.

Puppeteer launches a browser, usually headless (with no visible window), and gives you an API to open pages, click, type, run scripts in the page, intercept network requests and capture the result. page.pdf() turns a web page into a PDF using its print styles, which makes it a common way to generate invoices and reports from HTML templates.

It talks to Chrome over the Chrome DevTools Protocol and to Firefox over the WebDriver BiDi standard. It is a library rather than a test framework, with no test runner, parallel runs or reports built in, so for end-to-end testing Playwright, which the original Puppeteer authors went on to build, is the closer fit. Running it on serverless platforms needs a slimmed-down Chromium build.