Q380: Frontend Testing Drill Component Integration and E2E Boundaries

What Interviewers Want To Evaluate

This drill tests whether you can choose the right test for the risk.

Senior frontend engineers do not answer testing questions by saying everything needs unit tests or everything needs E2E tests.

They explain behavior, risk, confidence, cost, speed, and maintenance.

The interviewer wants to see whether your testing strategy protects users without slowing delivery unnecessarily.

Short Interview Answer

I choose frontend tests by risk and behavior. Pure logic gets unit tests, interactive components get component or integration tests, critical user journeys get E2E tests, accessibility checks cover keyboard and semantic behavior, and visual regression is useful for layout-sensitive surfaces. I avoid duplicating the same assertion at every layer.

Testing Pyramid For Frontend

A practical frontend testing model:

unit tests for pure logic
component tests for UI behavior
integration tests for state and API boundaries
E2E tests for critical journeys
visual tests for layout regressions
accessibility tests for inclusive behavior
contract tests for API assumptions

The pyramid is not a law.

It is a cost model.

The more browser-like the test, the more confidence it can provide and the more expensive it usually becomes.

Unit Test Candidates

Good unit tests:

formatCurrency
parseQueryParams
buildSearchUrl
sortResults
normalizeApiPayload
permission helpers
validation rules
reducers

These functions should be deterministic.

They should not require a browser.

If a unit test needs too much mocking, the boundary may be wrong.

Component Test Candidates

Good component tests:

form validation messages
button disabled states
accordion expand collapse behavior
modal focus behavior
search input interactions
table sorting controls
error fallback rendering

Component tests should verify what users can see or do.

Avoid testing implementation details like internal state variable names.

Integration Test Candidates

Use integration tests when behavior crosses boundaries:

component plus router
component plus data cache
form plus validation plus submit
search plus fake API responses
auth state plus permission UI
feature flag plus rendered experience

Integration tests are often the sweet spot for frontend apps.

They catch real behavior without the full cost of end-to-end infrastructure.

E2E Test Candidates

Use E2E for critical paths:

login
checkout
signup
core dashboard workflow
critical settings update
document creation
payment confirmation
permission-sensitive action

E2E should answer:

Can a real user complete the journey in a real browser?

Do not turn every component variation into an E2E test.

That creates slow, flaky suites.

Example Strategy

Feature: searchable user table with role filters.

Tests:

unit: build search query params
unit: normalize user API payload
component: filter chips toggle correctly
integration: query change loads latest results
integration: stale response cannot overwrite current results
accessibility: keyboard reaches input, filters, and rows
E2E: admin searches for a user and opens profile

This spreads confidence across layers.

Each layer has a job.

Accessibility Testing

Automated checks help find:

missing labels
contrast issues
invalid ARIA
landmark problems
button name issues

Manual checks still matter:

keyboard order
focus visibility
modal trapping
screen reader announcement quality
error recovery
dynamic update clarity

Accessibility is not one test command.

It is part of the behavior contract.

Mocking Strategy

Mock at the boundary you own.

Useful mocks:

network responses
time
browser APIs not available in test environment
feature flags
auth state
analytics sink

Avoid mocking:

the component under test
React behavior
too many internal hooks
implementation details

Mocking too deeply can make tests pass while users fail.

Flakiness Review

Common causes:

waiting for fixed time
unclear async completion
real network dependency
shared mutable test data
animations
timezone assumptions
non-deterministic ordering
test pollution

Prefer user-visible waits:

wait for heading
wait for result row
wait for alert
wait for URL change
wait for disabled state to clear

Tests should synchronize with behavior, not sleep.

Coverage Trap

Coverage can show whether code was executed.

It cannot prove the right behavior was tested.

A senior answer says:

I care about risk coverage more than line coverage.
Coverage is useful as a signal, but it should not replace journey-based test planning.

This is especially important for frontend apps where one line can affect a critical purchase or auth flow.

CI Strategy

Run:

unit and component tests on every pull request
typecheck on every pull request
lint or static checks on every pull request
focused E2E smoke tests on every pull request
full E2E and visual suite on scheduled or release gates

The exact split depends on suite speed and product risk.

The goal is fast feedback with enough release confidence.

Interview Answer Structure

Use:

identify critical user journeys
classify risks
choose test layer per risk
mock external boundaries
include accessibility
avoid duplicated assertions
manage CI speed
review flakiness

This shows you can build a sustainable quality system.

Common Mistakes

• Saying only unit tests matter.
• Saying only E2E tests matter.
• Testing implementation details.
• Ignoring accessibility behavior.
• Using fixed sleeps in async tests.
• Mocking so much that integration bugs disappear.
• Optimizing coverage number instead of user risk.
• Running slow suites on every tiny change without strategy.

Final Mental Model

Frontend testing strategy is:

behavior first
risk based
layered confidence
minimal duplication
fast feedback
real browser proof for critical journeys

Good tests help teams change code with less fear.