📘 Testing, Observability, and Release

A frontend ships to devices you do not control, cannot SSH into, and cannot roll back instantly (cached bundles live on in open tabs). So the design must say how you know it works before release, how you know it works after release, and how you undo a bad release.

Table of Contents

1. Testing Strategy
2. Test Types in Detail
3. Making Tests Reliable
4. Observability
5. Error Tracking
6. Analytics
7. CI/CD Pipeline
8. Progressive Delivery
9. Frontend Versioning and Skew
10. Incident Response
11. Questions

1. Testing Strategy

Two popular shapes:

Principle: test behavior the user can observe, not implementation details. Query by role and label, click and type like a user, and assert on visible output, so refactors do not break tests.

2. Test Types in Detail

2.1 What to Test Where

• Business rules and data transforms: unit tests.
• A form with validation and a server error: component test with MSW returning a 422.
• A feature's flow across components: integration test.
• Sign in, purchase, and other revenue paths: E2E.
• Design system components: Storybook stories as tests, visual and a11y checks.
• Server Components and framework routing: E2E or framework specific test utilities, because unit rendering does not reflect server behavior.

// runnable
// Testing behavior, not implementation: a tiny cart reducer with a table of cases.
function cartReducer(state, action) {
  switch (action.type) {
    case 'add': {
      const existing = state.items.find((i) => i.id === action.id);
      const items = existing
        ? state.items.map((i) => (i.id === action.id ? { ...i, qty: i.qty + 1 } : i))
        : [...state.items, { id: action.id, qty: 1, price: action.price }];
      return { ...state, items };
    }
    case 'remove':
      return { ...state, items: state.items.filter((i) => i.id !== action.id) };
    default:
      return state;
  }
}
const total = (s) => s.items.reduce((sum, i) => sum + i.qty * i.price, 0);

const cases = [
  { name: 'adds a new item', actions: [{ type: 'add', id: 'a', price: 10 }], total: 10 },
  { name: 'increments quantity', actions: [{ type: 'add', id: 'a', price: 10 }, { type: 'add', id: 'a', price: 10 }], total: 20 },
  { name: 'removes an item', actions: [{ type: 'add', id: 'a', price: 10 }, { type: 'remove', id: 'a' }], total: 0 },
];
for (const c of cases) {
  const result = c.actions.reduce(cartReducer, { items: [] });
  console.log(total(result) === c.total ? 'pass' : 'FAIL', '-', c.name);
}

3. Making Tests Reliable

Flaky tests destroy trust, and people stop reading red builds.

Operational habits: quarantine and fix a flaky test within days, track flake rate, retry only in CI with reporting (retries hide problems), and run E2E against a production-like build rather than the dev server.

4. Observability

You need to see what real users experience.

4.1 What to Collect

4.2 Practical Concerns

• Sampling: sample high volume signals (for example 10 percent of sessions), always capture errors.
• Batching and sendBeacon: send on visibilitychange (hidden) rather than unload, so data is not lost and bfcache is preserved.
• Correlation: generate a request id or W3C traceparent in the client and send it to the backend so one trace spans browser and server, and include it in error reports and support tickets.
• Release tagging: every event carries the build version and feature flag state, so regressions map to a deploy or experiment.
• Privacy: scrub PII, mask inputs in session replay, honor consent.
• Cost control: cap payload size, drop noisy events, aggregate before sending.
• Tools: OpenTelemetry for the web, Sentry, Datadog RUM, New Relic, Grafana Faro, and the web-vitals library.

5. Error Tracking

6. Analytics

• Event schema: name, properties, user or anonymous id, session id, timestamp, schema version, validated at build time (typed event helpers).
• Naming convention agreed with data teams (object_action, for example checkout_started).
• Batching and offline queue so events survive navigation and network loss.
• Exposure events for experiments, logged when the variant is actually shown.
• Consent and privacy gates, server side collection where possible.
• Avoid blocking the main thread with tag managers, load analytics after critical content.
• Deduplication: idempotent event ids, since retries and double renders create duplicates.
• Data quality tests: verify key events fire in E2E tests.

7. CI/CD Pipeline

8. Progressive Delivery

Rollback specifics for web:

• Because users keep old tabs and cached HTML, a rollback does not immediately change what everyone runs.
• Keep backward compatible APIs (expand then contract), so the old and new clients both work during rollout.
• A version check (the app polls a version file or reads a response header) can prompt "new version available, reload" or force a refresh for a critical fix.
• Service workers need an update path, or a stuck old worker keeps serving a broken shell: ship a killing service worker that unregisters itself if necessary.

9. Frontend Versioning and Skew

Version skew happens when the client and server (or old and new assets) are different versions.

Rule: deploy the backend first with backward compatibility, then the frontend, then remove old paths later.

10. Incident Response

1. Detect: alert fires from RUM or error tracking (error rate, vitals regression, drop in conversion).
2. Triage: which release, route, browser, or flag? Compare to the previous version.
3. Mitigate first: turn off the flag, roll back, or shift traffic, then investigate.
4. Communicate: status page, support notes with the error id.
5. Fix forward with a test that reproduces the bug.
6. Postmortem: blameless, with action items (missing alert, test, rollout guard).

11. Questions

Q: What is your frontend testing strategy? Static analysis everywhere, unit tests for logic, mostly component and integration tests that exercise behavior with a mocked network, a thin layer of Playwright E2E for critical journeys, visual and accessibility checks for the design system, and performance budgets in CI.

Q: Why are E2E tests flaky and how do you reduce it? Timing, shared state, real network, and unstable selectors. Use auto waiting, isolated contexts and data, mocks for third parties, role based selectors, and a production-like build.

Q: How do you test components that fetch data? Render with a provider, mock the network at the boundary with MSW, assert loading, success, empty, and error states, and avoid mocking the data hooks themselves.

Q: What do you monitor after a release? Error rate by release, Web Vitals by route, API failure rates seen from the client, key conversion events, and chunk load failures, with automated rollback thresholds.

Q: How do you roll back a frontend? Redeploy or switch to the previous artifact, disable the flag, and keep assets and APIs backward compatible so open tabs keep working. Account for cached HTML and service workers.

Q: What is version skew and how do you handle it? Mismatch between client assets and the server or between HTML and chunks. Use hashed immutable assets with old versions retained, additive API changes, a version check that prompts reload, and deploy backend first.

Q: How do you connect a frontend error to a backend log? Generate a request or trace id on the client (W3C traceparent), send it as a header, log it on the server, and attach it to error reports and support tickets.

Q: How do you stop performance regressions? Bundle size limits and Lighthouse CI in pull requests, RUM dashboards and alerts per route, canary rollouts that compare vitals between versions, and route ownership.

Q: What is a canary release for a web app? Send a small percentage of users, bucketed by a cookie or header at the edge, to the new version while monitoring errors and vitals, then increase gradually or roll back.

Q: Unit tests pass but production breaks. Why? Mocks that diverge from the real API (use contract tests), environment differences, untested integration paths, cache and skew issues, and device or browser specifics. Add integration tests, contract checks, and production monitoring.

Next: UI Component Designs.