Testing

Option 1: Mock the fetch/axios function

Option 2: Mock the module

Option 3: Use MSW (Mock Service Worker)

MSW is preferred for realistic network mocking.

Option 1: Colocated (Recommended)

Option 2: Separate test directory

Naming conventions:

• Component.test.js - Unit tests
• Component.spec.js - Specs (BDD style)
• Component.e2e.js - E2E tests

Using userEvent (preferred) or fireEvent:

userEvent simulates real user behavior; fireEvent is lower-level.

Priority order:

1. getByRole (accessibility)
2. getByLabelText (forms)
3. getByText (non-interactive elements)
4. getByTestId (last resort)

The Testing Pyramid: Many unit tests at the base, fewer integration tests in the middle, fewest E2E tests at the top.

Replacing real dependencies with fake implementations to isolate the code under test.

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

Key principles:

• Query by accessibility roles, labels, text (not implementation details)
• Test behavior, not implementation
• If you can't find an element, neither can a user

A structure for organizing test code:

Also known as Given-When-Then in BDD.

Kent C. Dodds' alternative to the Testing Pyramid:

Key idea: Integration tests give the best cost/confidence ratio.

• Unit Test: Tests a single function or component in isolation. Dependencies are mocked.
• Integration Test: Tests how multiple units work together. Uses real (or partially real) dependencies.

FIRST principles:

• Fast: Tests should run quickly
• Isolated: No dependencies on other tests
• Repeatable: Same result every time
• Self-validating: Pass or fail, no manual checking
• Timely: Written close to the code being tested

Additional qualities:

• Tests one thing
• Clear failure messages
• Readable as documentation

Using @testing-library/react-hooks or renderHook:

Using fake timers:

Flaky tests pass or fail inconsistently without code changes.

Common causes:

• Race conditions (async timing)
• Shared state between tests
• External dependencies
• Animation/transition timing

Fixes:

An extension of TDD focused on describing behavior in plain language.

Tools: Cucumber, Cypress (with Gherkin plugins).

Difference from TDD: BDD focuses on user behavior; TDD focuses on implementation.

Code coverage measures how much of your code is executed during tests.

Types:

• Line coverage: % of lines executed
• Branch coverage: % of if/else branches taken
• Function coverage: % of functions called

Limitations:

• 100% coverage ≠ bug-free code
• Doesn't measure test quality
• Can encourage writing tests just to hit numbers

Capturing output and comparing it to a stored version.

Pros: Easy to set up, catches unexpected changes. Cons: Easy to blindly update snapshots, large diffs are hard to review.

Best practice: Keep snapshots small and focused.

Each test should be independent and not affect other tests.

Problems with shared state:

• Tests pass individually, fail together
• Order-dependent failures
• Hard to debug

Solutions:

A development process where you write tests before writing the implementation.

Red-Green-Refactor cycle:

1. Red: Write a failing test
2. Green: Write minimal code to pass the test
3. Refactor: Improve code while keeping tests green

Benefits: Better design, fewer bugs, documentation through tests.

• Shallow rendering: Renders only the component itself, not children. Fast but less realistic.
• Full rendering (mount): Renders the entire component tree. Slower but tests real behavior.

Modern approach: Testing Library encourages full rendering to test real user experience.

Verifying that API providers and consumers agree on the interface.

Tools: Pact, Spring Cloud Contract.

The contract is verified against the real provider during CI.

Passing dependencies into a function/class instead of creating them internally.

Testing the entire application from the user's perspective, including frontend, backend, and database.

Tools: Cypress, Playwright, Selenium

Automatically modifying your code (mutations) to see if tests catch the changes.

Example mutations:

• Change > to <
• Replace true with false
• Remove statements

Tools: Stryker, PIT (Java).

Result: If tests still pass after a mutation, your tests have gaps.

Comparing screenshots of UI components to detect unintended visual changes.

Tools: Percy, Chromatic, Playwright's screenshot comparison.

Workflow: Baseline images → Run tests → Compare → Review diffs.

Cypress: Better DX, great for beginners. Playwright: More powerful, better for complex scenarios.

• Pure functions: No side effects, no need to mock
• Simple value objects: Just use real data
• When testing integration: You want real interactions
• When mocks become complex: Sign of design issues

Over-mocking leads to tests that pass but don't catch real bugs.