Q185: React Testing Strategy for Hooks, Components and Flows

What Interviewers Want To Evaluate

This question checks whether you can test React behavior at the right level. Interviewers want unit tests, component tests, hook tests, integration tests, E2E tests, accessibility checks, mocking strategy, async UI, Server Component boundaries, and avoiding brittle implementation tests.

Senior answers should connect tests to risk and confidence.

Short Interview Answer

A good React testing strategy tests behavior at the smallest level that gives confidence. Pure utilities can use unit tests, reusable components need interaction and accessibility tests, hooks need focused behavior tests when logic is complex, and critical user workflows need integration or E2E coverage. I avoid testing implementation details like internal state names and instead test what users can observe, including loading, errors, keyboard behavior, and async recovery.

Detailed Interview Answer

React testing should match risk.

utility function: unit test
custom hook: behavior test
button or field: component test
form workflow: integration test
checkout or login: E2E test
route generation: build test
accessibility contract: a11y and keyboard test

Not every component needs every test type.

Unit Tests

Use unit tests for pure logic.

Examples:

formatters
reducers
validators
filter functions
permission helpers
state transition utilities
frontmatter parsers

Pure logic is cheap to test and easy to reason about.

Component Tests

Component tests should focus on behavior.

renders label
opens menu on click
supports keyboard navigation
shows validation error
calls callback with correct value
disables submit while pending
announces success message

Avoid testing internal state variable names.

Hook Tests

Custom hooks deserve direct tests when they contain meaningful logic.

Examples:

useLocalStorageState
useReadingProgress
useEventListener
useDebouncedValue
useAsyncResource
useKeyboardShortcuts

If a hook is just one useState, direct tests are probably not worth it.

Integration Tests

Integration tests cover multiple components working together.

Examples:

form field plus validation summary
practice editor plus console output
reader progress widget plus local storage
batch page plus question links
cheat sheet filter plus cards

This level catches wiring bugs.

E2E Tests

E2E tests cover critical user workflows in a real browser.

Examples:

open handbook
navigate to latest volume
read question and mark progress
reset progress
run JavaScript practice code
copy console output
open cheat sheet
download PDF link

Keep E2E coverage focused. Too many broad E2E tests become slow and flaky.

Accessibility Testing

Accessibility needs automated and manual coverage.

Automated checks can catch:

missing labels
color contrast
invalid aria
landmark issues
heading problems

Manual checks are still needed for:

keyboard flow
focus order
screen reader announcements
modal behavior
complex grid navigation

Async UI Tests

Async UI tests should cover:

loading state
success state
error state
retry
stale response prevention
pending mutation behavior
optimistic rollback
slow network behavior

Do not test only the happy path.

Mocking Strategy

Mock at the boundary.

Good mocks:

network responses
browser APIs
time
local storage
feature flags
auth session

Avoid mocking the component under test so heavily that the test proves nothing.

Server Components and Next.js

For Next.js content-heavy apps, build verification matters.

Testing should include:

frontmatter parsing
static route generation
metadata generation
server/client boundary safety
practice API route behavior
production build

Some issues only appear during next build.

Common Mistakes

A common mistake is testing implementation details.

Another mistake is skipping accessibility behavior.

Another mistake is mocking away the bug.

Another mistake is relying only on snapshots.

Another mistake is having E2E tests for everything and unit tests for nothing.

Senior Trade-Offs

Testing is a portfolio.

Use fast tests for logic, component tests for reusable behavior, integration tests for wiring, and E2E tests for critical workflows.

The goal is confidence with maintainable cost.

Debugging Workflow

When tests are flaky:

remove timing assumptions
wait for user-visible state
mock unstable external boundaries
avoid shared global state
reset storage between tests
prefer role-based queries
avoid snapshots for dynamic UI
run failing test repeatedly

Interview Framing

Explain the test pyramid as risk-based coverage, then map React utilities, hooks, components, async flows, accessibility, and E2E workflows to the right test levels.

Revision Notes

Good tests describe behavior users or other components rely on.

Key Takeaways

Test behavior and contracts, not private implementation details.

Follow-Up Questions

1. What should unit tests cover?
2. When should hooks be tested directly?
3. What makes component tests valuable?
4. What belongs in E2E tests?
5. Why are snapshots limited?
6. How do you test async UI?
7. How do you test accessibility?
8. What should be mocked?
9. How does Next.js build testing help?
10. How do you reduce flaky tests?

How I Would Answer This In A Real Interview

I would say I choose test level by risk. Pure logic gets unit tests, reusable components get behavior and accessibility tests, complex hooks get focused tests, and critical workflows get E2E coverage. I would include loading, errors, keyboard paths, and build verification for Next.js content routes.