How to Test JavaScript Apps

You finish a feature, click through the happy path once, and move on. Then someone submits a one-character search, the API returns an empty array, or the first request fails. If the screen gives them no useful response, the feature was never really finished.

The short answer to how to test JavaScript apps is to test each risk at the smallest layer that can prove it: pure logic with unit tests, visible UI and request behavior with integration tests, server behavior with HTTP tests, and only your highest-risk journey in a real browser. Start by defining what the user can see when things go right and wrong.

JavaScript app testing checklist

Copy this into a pull request, release plan, or test-plan document before you write tests.

Get the Mobile Testing Playbook Used by 800+ QA Teams

Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.

Email addressGet Instant Access

100% Free. No spam. Unsubscribe anytime.

Map each visible state to a test layer

Use one small screen as a running example: it loads a list of items, shows a loading message, renders records or an empty state, recovers from a failed request, and submits a validated form. MDN’s testing guide explains why a sufficiently complex codebase needs tests to keep meeting user needs as it changes. Your job is to turn that broad need into observable contracts.

This matrix is not a universal testing ratio. It is a decision tool: for every feature, identify what can fail, what a user or client should observe, and the lowest-cost test that can establish the behavior.

Step 1: Test pure JavaScript logic

Start with deterministic functions that do not need a DOM, server, or browser. Validation, parsing, formatting, and boundary calculations are good candidates because a focused unit test can explain their intent quickly.

Write cases around the boundary instead of only confirming one normal value:

Use the runner already established in your repository. Jest’s getting-started documentation covers installing Jest, creating test files, and running them. A Vite-based project may instead use Vitest; the choice of runner is less important than putting deterministic behavior in a fast, isolated test.

Step 2: Test the UI through the user-visible contract

An integration test should render the screen, interact with controls, and assert the resulting interface. Testing Library recommends user-centric tests rather than implementation-detail assertions, while its user-event documentation describes more complete interaction simulation than low-level event dispatch.

For the example form, work in this order:

1. Render the screen with its normal dependencies.

2. Find the input by its accessible label and the control by its accessible role.

3. Type invalid input and submit.

4. Assert that the validation message is visible and that the request was not made.

5. Type valid input, submit again, and await the visible result.

This test describes a contract the user can observe. Avoid testing private hook state, component instances, or CSS class names unless that exact detail is part of the requirement. A refactor can change internals without changing what the reader sees; your test should survive that refactor.

Step 3: Test API states at the network boundary

Your screen needs explicit behavior for more than a successful response. Mock Service Worker (MSW) is designed to intercept network traffic in browser and Node.js environments, which makes it useful for integration tests that should exercise the same request boundary as the app.

Create handlers for these five conditions:

1. Success: return records and assert that loading feedback disappears before records appear.

2. Empty: return a valid empty list and assert the empty-state copy and next action.

3. Failure: return a server error or reject the request, then assert error copy and a retry control.

4. Malformed data: return a response missing a required field, then assert a safe error state rather than a broken render.

5. Retry: fail the first request, make the retry succeed, and assert recovery without a page reload.

A retry test can look like this conceptually:

Mocking here proves that your UI handles a defined network shape. It does not prove that the production server returns that shape. Keep that distinction clear, then test the server directly.

Step 4: Make asynchronous tests prove they finished

A test that starts asynchronous work but does not return or await it can pass before its assertion runs. Jest’s asynchronous testing guide documents awaiting promises and using expect.assertions() to ensure an assertion in a rejection or callback path actually executes.

Use a direct rejection matcher when you expect a failed request:

For UI tests, await both the interaction and the resulting condition. Use findBy... queries or the wait utilities supplied by your test library when the UI changes after a request. Do not add a fixed setTimeout or a browser sleep merely to make a failure disappear. A fixed delay guesses when work finishes; an assertion on the visible result establishes that it did.

Step 5: Test the backend with an HTTP test

Use a backend HTTP test when you need evidence about the server itself: response status, headers, authorization, validation, persistence effects, and response body shape. The maintained Supertest repository documents its fluent API for Node.js HTTP-server testing and supports passing an app directly to request().

Expand the example based on your actual API, not a generic checklist alone. Test missing or malformed input, unauthenticated and unauthorized access, not-found responses, conflicts or validation failures, and server-error behavior where those outcomes exist. If independently versioned systems consume your API, contract testing may be an additional discipline; a single endpoint test does not replace it.

Step 6: Add one high-value browser test

End-to-end tests are most useful when they prove a complete journey that lower-level tests cannot fully cover. Playwright provides a browser test runner with isolation, multiple browser projects, and assertions. Keep this layer deliberately small.

For the example app, choose a journey with real release risk:

1. Open the item page.

2. Fill the labeled form fields with valid data.

3. Submit the form.

4. Assert the visible confirmation or resulting URL.

5. Check a network result only when it makes a failure easier to diagnose.

Playwright’s assertion guidance describes web-first assertions that wait for the expected condition. Use those assertions instead of waitForTimeout. Its network guidance is available when observing or modifying browser traffic adds diagnostic value, but do not turn every browser test into a duplicate of your integration suite.

Step 7: Run the suite in CI and keep the failure evidence

A green local run is useful; repeatable pull-request evidence is better. Playwright’s CI guide documents the core GitHub Actions sequence: check out code, install Node dependencies and browsers, run tests, and upload the HTML report.

Adapt this workflow to your package scripts and supported action versions:

When CI fails, inspect logs and the HTML report first. If you configured screenshots, video, or traces, inspect those too. Then classify the failure before editing: is it a product defect, a broken test, leaked data between tests, an environment problem, or a timing problem? That classification prevents you from “fixing” a real regression by weakening its test.

Step 8: Separate browser evidence from React Native and device evidence

If you ship a React Native build, browser coverage is not evidence that the native app behaves correctly. React Native’s testing overview covers testing from static analysis through E2E and recommends reserving slower end-to-end coverage for important flows.

Plan device or emulator E2E checks for risks that depend on the native runtime:

• lifecycle and background or process transitions;

• runtime permissions;

• keyboard and back-button behavior;

• safe areas and device-specific layout;

• offline and online transitions; and

• platform-specific rendering or navigation.

A browser test can establish that your web JavaScript flow works. It cannot establish how a mobile operating system, device keyboard, permission prompt, or native navigation stack will behave.

Conclusion

To test JavaScript apps without building an expensive, duplicated suite, begin with the state matrix. Put each changed behavior where it can fail: pure rules in unit tests, visible UI and mocked requests in integration tests, server contracts in HTTP tests, and only the critical journey in a browser test. Update that map whenever the feature changes, and your next test will have a clear purpose before you choose a tool.