Testing

Pure functions — utils, formatters, reducers, validators. Anything where given the same input you get the same output. These are the cheapest tests and the most valuable per minute spent.

I avoid testing implementation details of components at the unit level — that's RTL territory.

In order of preference:

1. Don't. Refactor to inject the dependency, then pass a fake in the test. Cleaner code and cleaner tests.
2. Mock at the module boundary — jest.mock('./api') for API calls. Keep mocks shallow.
3. MSW (Mock Service Worker) for HTTP-level mocking. Best of both worlds — your real fetch code runs, MSW intercepts at the network layer.

The mocking smell: tests that mock 12 things to test 1. That's a sign the unit under test has too many responsibilities.

The name reflects the philosophy: test the way users interact with your UI, not the implementation details of your component. The guiding principle on the website: "the more your tests resemble the way your software is used, the more confidence they can give you."

RTL provides queries in a recommended priority order:

1. Accessible to everyone — getByRole, getByLabelText, getByPlaceholderText, getByText
2. Semantic queries — getByAltText, getByTitle
3. Test ID — getByTestId — last resort

If your test can find an element with getByRole('button', { name: /submit/i }), you've also verified the button is accessible. Tests that lean heavily on testIDs are a code smell — usually means the markup isn't accessible.

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { OrderForm } from './OrderForm';

test('submits with the entered SKU', async () => {
  const onSubmit = jest.fn();
  const user = userEvent.setup();

  render(<OrderForm onSubmit={onSubmit} />);

  await user.type(screen.getByLabelText(/sku/i), 'ABC-123');
  await user.click(screen.getByRole('button', { name: /submit/i }));

  expect(onSubmit).toHaveBeenCalledWith({ sku: 'ABC-123' });
});

Note: userEvent.setup() is preferred over fireEvent — it simulates real user interactions more faithfully.

Use findBy* queries and waitFor:

// findBy* waits up to a default timeout
expect(await screen.findByText(/order created/i)).toBeInTheDocument();

// waitFor for arbitrary assertions
await waitFor(() => expect(onSubmit).toHaveBeenCalled());

For API calls, use MSW to intercept and respond — your component's real fetch logic runs against a fake server.

• Testing implementation — expect(component.state.x). Just test the rendered output and behavior.
• Snapshot tests for everything — bloated, brittle, no one reads them when they break. Use snapshots sparingly for stable, hard-to-describe outputs.
• Over-mocking — mocking the world to test almost nothing.
• Using container.querySelector when an RTL query exists. The escape hatch is for legitimate edge cases, not laziness.
• act() warnings ignored — they signal real issues with timing.

Both are good. Playwright wins for me on:

• Multi-browser — Chromium, Firefox, WebKit out of the box.
• True parallelism across browsers and projects, much faster CI.
• Auto-waiting — most flakiness vanishes without explicit waits.
• Network interception — first-class API for mocking, recording, replaying.
• Trace viewer — debugging failed CI runs is genuinely good.

Cypress has a really nice DX for interactive use and great docs. Either is defensible. For Omnesoft (Playwright in the JD), Playwright.

import { test, expect } from '@playwright/test';

test('user can create an order', async ({ page }) => {
  await page.goto('/orders/new');
  await page.getByLabel('SKU').fill('ABC-123');
  await page.getByLabel('Quantity').fill('5');
  await page.getByRole('button', { name: 'Submit' }).click();

  await expect(page.getByText('Order created')).toBeVisible();
});

Note Playwright's getBy* locators mirror RTL semantics — query by accessible name first, fall back to test IDs.

• Run them in parallel. Playwright does this by default — make sure tests don't depend on shared state.
• Use storage state for auth — log in once, reuse the session across tests instead of logging in per test.
• Seed the backend or use fixtures — don't rely on UI flow to set up test data. Hit the API directly to create state.
• Smoke set on every PR, full suite on main — keep PR feedback fast.
• Trace viewer + screenshots on failure — make CI failures debuggable.
• Stable selectors — accessible names first, test IDs second.
• Avoid sleeps. Use Playwright's auto-waiting locators.

Sometimes. Tools: Chromatic (Storybook-based), Playwright's built-in screenshot diffing, Percy. Big trade-off: maintenance — diffs flag intentional changes too, and reviewing them adds review burden. I'd reach for it when there's a real design-consistency stake (a public-facing landing page, a design system) and skip it for an internal ERP UI where visual exactness is less of a concern than behavior.

Multiple layers:

1. Automated — jest-axe in unit tests, @axe-core/playwright in E2E. Catches obvious issues like missing labels, contrast failures, ARIA misuse.
2. RTL queries themselves — using getByRole exercises the accessibility tree. If a query can't find your button by role, the button isn't accessible.
3. Manual keyboard testing — tab through anything significant before shipping. If you can't, neither can your users.
4. Screen reader spot checks — VoiceOver on macOS, NVDA on Windows. Not on every PR, but on critical flows.

Automated tools catch ~30% of real issues. The rest need human testing. That's worth saying out loud — interviewers like seeing nuance here.