Appearance

Frontend Unit Testing with Jest ​

Pragmatic approaches to frontend unit testing using Jest and React Testing Library

Related Concepts: Unit Testing | Test-Driven Development | Clean Architecture | Acceptance Testing

Table of Contents ​

  1. Testing Philosophy
  2. Why React Testing Library
  3. Semantic Selectors Philosophy
  4. Component Testing Strategy
  5. Integration-Focused Unit Tests
  6. AHA Testing Principles
  7. What NOT to Test
  8. Mocking Philosophy
  9. Key Principles
  10. Further Reading

Testing Philosophy ​

The Testing Trophy and Pragmatic Testing ​

Frontend developers are often familiar with Kent C. Dodds' "Testing Trophy" which suggests writing more integration tests than unit tests. This aligns perfectly with our sociable testing approach - we believe in testing behavior clusters rather than isolated units.

The core principle, as Kent C. Dodds puts it:

"The more your tests resemble the way your software is used, the more confidence they can give you."

This philosophy means prioritizing:

  • User behavior over implementation details - Test what users actually experience
  • Real component interactions over mocked isolation - Components rarely work alone in production
  • Observable outcomes over internal mechanics - If users can't see it, why test it?

Rather than obsessing over test shapes or percentages, we focus on fundamental qualities:

  • Fast feedback - Rapid iteration requires quick test execution
  • Clear failures - Immediately understand what broke and why
  • Maintainability - Tests should evolve with the code, not fight against it
  • Confidence - Tests must catch real bugs that affect users

Why React Testing Library ​

Enforcing Good Testing Practices ​

React Testing Library isn't just another testing utility - it's an opinionated framework that makes it difficult to test the wrong things. By limiting access to component internals and encouraging interaction through accessible queries, it naturally guides developers toward testing what matters.

The library's constraints are its strength. When you can't easily access component state or internal methods, you're forced to think about your component from the user's perspective. This shift in thinking leads to more robust, maintainable tests that survive refactoring.

Semantic Selectors Philosophy ​

Accessibility as a Testing Strategy ​

The preference for semantic selectors isn't arbitrary - it reflects how real users and assistive technologies interact with your application. When you query by role, label, or text content, you're implicitly testing that your application is accessible and usable.

This hierarchy of queries serves multiple purposes:

  • Ensures accessibility - If you can't query it semantically, users might struggle too
  • Documents intent - Semantic queries describe what elements do, not how they're implemented
  • Promotes stability - Semantic queries survive styling and structural changes

The principle is simple: the harder it is to query an element with semantic selectors, the harder it is for users to interact with it.

Component Testing Strategy ​

Sociable Components Over Isolated Units ​

In frontend development, the "unit" in unit testing is misleading. Components don't exist in isolation - they're composed, nested, and interconnected. Testing them in isolation often means testing implementation details that don't reflect real usage.

Our sociable testing approach for components means:

  • Testing component clusters - Components with their children, as they appear to users
  • Preserving real relationships - Context providers, HOCs, and composition patterns intact
  • Focusing on user journeys - Complete interactions rather than individual method calls

This approach reveals integration issues early, reduces mock complexity, and produces tests that better represent production behavior.

Integration-Focused Unit Tests ​

The False Dichotomy of Unit vs Integration ​

For frontend testing, the distinction between unit and integration tests is often artificial. What matters isn't the classification but the value: does this test provide confidence that the feature works?

Integration-focused unit tests acknowledge that:

  • Components are naturally integrated - They use context, routing, and state management
  • User actions span multiple components - A single click might trigger updates across the UI
  • Real confidence comes from realistic scenarios - Isolated components tell us little about system behavior

By embracing integration within our "unit" tests, we get faster feedback than E2E tests while maintaining the realism that provides confidence.

AHA Testing Principles ​

Avoid Hasty Abstraction in Tests ​

Kent C. Dodds' AHA (Avoid Hasty Abstraction) principle is particularly important for test code. The temptation to DRY up tests through abstraction often leads to tests that are harder to understand and maintain than duplicated code would be.

The principle recognizes that:

  • Test clarity trumps code reuse - Each test should tell a complete story
  • Duplication is better than wrong abstraction - Premature test utilities obscure intent
  • Tests are documentation - They should be readable in isolation

The key insight: test code has different constraints than production code. While production code benefits from abstraction to manage complexity, test code benefits from explicitness to maintain clarity.

What NOT to Test ​

The Implementation Detail Trap ​

The most common testing mistake in frontend development is testing implementation details. These tests are fragile, provide false confidence, and actively harm refactoring efforts.

Implementation details include:

  • Component state variables - Users don't see or care about your state management
  • Method invocations - Testing that functions were called tests structure, not behavior
  • Component lifecycle - Framework mechanics aren't user concerns
  • CSS classes and structure - Unless they affect functionality

The litmus test is simple: would a user notice if this changed? If not, don't test it.

Third-Party Code ​

Testing framework functionality or library behavior wastes effort and provides no value. Trust that React, React Router, and other dependencies work as advertised. Focus your testing energy on your application's unique behavior.

Mocking Philosophy ​

Mock at the Boundaries, Not the Center ​

Our sociable testing philosophy extends to mocking strategy. Mock only what you must - external services, network calls, and system boundaries. Everything else should use real implementations.

This approach:

  • Reduces test brittleness - Fewer mocks mean fewer assumptions about implementation
  • Catches integration bugs - Real components reveal real issues
  • Simplifies test setup - Less mocking ceremony means clearer tests
  • Improves confidence - Tests with real components better reflect production

Tools like MSW (Mock Service Worker) exemplify this philosophy by mocking at the network layer, allowing your entire application stack to remain real while controlling external dependencies.

Key Principles ​

Test the Contract, Not the Implementation ​

Frontend components have an implicit contract with users: given certain interactions, produce certain outcomes. Tests should verify this contract without concerning themselves with how it's fulfilled.

Fast Feedback Over Perfect Coverage ​

A test suite that runs in seconds and covers critical paths is more valuable than one that takes minutes but covers every edge case. Fast tests get run frequently, catching bugs sooner.

Behavior Over Structure ​

Test what components do, not what they are. A button that submits a form is defined by that behavior, not by its DOM structure or event handlers.

Confidence Through Realism ​

The closer tests are to real usage, the more confidence they provide. This doesn't mean only writing E2E tests, but ensuring that even unit tests reflect realistic scenarios.

Further Reading ​

Kent C. Dodds Articles ​

Testing Library Documentation ​

Internal Documentation ​

Conclusion ​

Effective frontend testing combines Kent C. Dodds' user-centric testing philosophy with our pragmatic sociable testing approach. The goal isn't to achieve testing perfection or follow rigid rules, but to build confidence that your application works for users and can be safely changed.

Remember: the shape of your test pyramid matters less than the quality of your tests. Focus on writing tests that are fast, clear, and realistic. Test behavior, not implementation. And always ask yourself: "Would a user care about this?"

For backend testing approaches, see our Unit Testing and Backend Integration Testing guides.