Mastering Frontend Automated Testing: From Unit to E2E

Preface: Automated Testing in Frontend

For frontend developers, automated testing is both valuable and challenging; it provides confidence that changes won’t break existing logic, yet fast‑changing pages often make writing tests feel burdensome.

Even for quickly iterated pages, shared utility functions and SDKs deserve thorough test coverage, especially for high‑traffic, long‑lived pages that require multiple testing scenarios.

This article introduces the basics of frontend testing, helping readers understand how to write test cases and which scenarios to cover.

Unit Testing and Integration Testing

Unit testing targets individual code units, such as utility functions, using a "functional unit" approach to determine granularity. External dependencies are mocked so each unit can be tested in isolation.

Common mock types include Fake, Stub, Mock, and Spy.

When a function’s behavior depends on external calls (e.g., fetch), you can replace the external implementation to verify different branches, checking whether callbacks like

processData

or

reportError

are invoked.

Complete unit‑testing setups typically include assertions, test collection, mocking utilities, and coverage reporting.

Assertions: Jest’s global

expect

, Sinon’s assert style, or Chai assertions.

Test collection: use

describe

to group a feature and

it

/

test

for individual cases.

<code>describe('Utils.Reporter', () => {
  it('should report error when xxx', () => {})
  it('should show warnings when xxx', () => {})
})</code>

Mocking: Stubs, fakes, spies, and module mocks.

Coverage reports: generated via Istanbul/nyc or c8, with optional JUnit output.

For a fast, TypeScript‑friendly solution, the author recommends Vitest, which integrates well with Vite and provides a UI for test results.

Integration Testing

Integration testing verifies the collaboration of multiple units without testing the entire system. It can be performed using the same unit‑testing tools, simply grouping related units into a larger scenario.

Mock, Fake, Stub

Testing often requires avoiding real network requests, database access, or DOM APIs. Stubs replace dependencies (e.g., a PrismaServiceStub), fakes provide in‑memory implementations (e.g., a fake database or timer), and mocks represent expected inputs without focusing on return values.

Assertions: expect, assert, should

Common assertion styles include

expect

(Jest/Testing Library),

assert

(Node’s asserts), and

should

(Chai’s chainable style).

<code>expect(mockFn).toBeCalledWith("linbudu");
assert.pass(mockFn.calls[0].arg === "linbudu");
expect(obj1).toEqual(obj2);
assert.equal(obj1, obj2);
mockFn.should.be.called();
obj1.should.equal(obj2);</code>

Component Testing and E2E Testing in Frontend

Beyond unit and integration tests, component testing validates UI and behavior of isolated components (e.g., React components) using tools like

@testing-library/react

or Enzyme. The author prefers Testing Library for its simplicity and ongoing support.

<code>import * as React from 'react'
function HiddenMessage({children}) {
  const [showMessage, setShowMessage] = React.useState(false)
  return (
    <div>
      <label htmlFor="toggle">Show Message</label>
      <input id="toggle" type="checkbox" onChange={e => setShowMessage(e.target.checked)} checked={showMessage} />
      {showMessage ? children : null}
    </div>
  )
}
export default HiddenMessage

import {render, fireEvent, screen} from '@testing-library/react'
import HiddenMessage from '../hidden-message'

test('shows the children when the checkbox is checked', () => {
  const testMessage = 'Test Message'
  render(<HiddenMessage>{testMessage}</HiddenMessage>)
  expect(screen.queryByText(testMessage)).toBeNull()
  fireEvent.click(screen.getByLabelText(/show/i))
  expect(screen.getByText(testMessage)).toBeInTheDocument()
})</code>

E2E testing simulates real user flows (e.g., login → search → add to cart → checkout) using browsers. Popular frameworks include Puppeteer, Cypress, Playwright, and Selenium.

Puppeteer, Cypress, Playwright Choices

Use Puppeteer for very simple scenarios (requires Jest‑Puppeteer), Cypress for desktop web applications, and Playwright for cross‑browser and mobile testing. Playwright supports multiple projects and device presets, making it suitable for mobile‑first testing.

<code>// playwright.config.ts
import { PlaywrightTestConfig, devices } from '@playwright/test'

const config: PlaywrightTestConfig = {
  projects: [
    { name: 'Desktop Chromium', use: { browserName: 'chromium', viewport: { width: 1280, height: 720 } } },
    { name: 'Desktop Safari', use: { browserName: 'webkit', viewport: { width: 1280, height: 720 } } },
    { name: 'Desktop Firefox', use: { browserName: 'firefox', viewport: { width: 1280, height: 720 } } },
    { name: 'Mobile Chrome', use: devices['Pixel 5'] },
    { name: 'Mobile Safari', use: devices['iPhone 12'] },
  ],
}
export default config
</code>

For UI component libraries, Storybook can generate visual documentation and E2E tests via Jest and Playwright.

Backend Service E2E and Stress Testing

Backend E2E tests simulate client requests (e.g., using supertest) to verify API responses without concerning internal controllers or services. Mocking can involve test databases or stubbing external services.

Stress testing evaluates performance under load, measuring metrics such as RPS, concurrency level, TPS, and response time, using tools like Apache Bench, wrk, or autocannon, and can be aided by Node’s profiling flags (--prof, --prof-process) or heapdump.

Conclusion

The article surveys the main categories of automated testing relevant to frontend developers—unit, integration, component, E2E, performance, accessibility, and even chaos testing—providing practical guidance on when and how to apply each approach.