Testing: Building Confidence in Your Code

📋 Table of Contents

• 🎯 Sprint Goal
• 📍 Position in Journey
• 🧭 Learning Objectives
• 🏗️ The Testing Trophy
• 🔧 Testing Stack
• 🎓 Methodology: Atelier Practice
  • The Sprint Rhythm
  • What to Test (Priority Order)
  • AI-Assisted Development Protocol
• 📝 Sprint Deliverables
• 💡 Test Examples
  • Unit Test (Vitest)
  • Component Test (RTL)
• 🔗 Lesson Navigation
• 📚 Key Concepts Preview
  • What “good testing” means (in this course)
  • Minimal stack (recommended)
  • Example: test behavior, not structure
  • Reflection (Atelier)
  • Koan

“Tests are not about finding bugs. Tests are about building confidence to change.”

🎯 Sprint Goal

By the end of this sprint: Your app has a testing foundation—unit tests for logic, component tests for UI behavior, and at least one end-to-end test for a critical user flow.

📍 Position in Journey

🧭 Learning Objectives

By the end of this lesson, you will:

• Write unit tests for pure functions and hooks
• Test React components with React Testing Library
• Mock API calls in component tests
• Write at least one Cypress E2E test
• Understand the Testing Trophy (what to test most)
• Set up CI to run tests on every push

🏗️ The Testing Trophy

                    ┌───────┐
                    │  E2E  │  ← Few, critical paths
                    └───┬───┘
                   ┌────┴────┐
                   │Integration│  ← Most of your tests
                   └────┬─────┘
                 ┌──────┴──────┐
                 │    Unit     │  ← Pure functions, hooks
                 └──────┬──────┘

Focus: Does the user's goal get accomplished?
Avoid: Testing implementation details

🔧 Testing Stack

🎓 Methodology: Atelier Practice

The Sprint Rhythm

┌─────────────────────────────────────────────────────────┐
│ DAY 1: Unit & Component Tests                           │
│   • Set up Vitest and React Testing Library             │
│   • Write unit tests for utility functions              │
│   • Test a form component (render, type, submit)        │
├─────────────────────────────────────────────────────────┤
│ DAY 2: Integration & Mocking                            │
│   • Set up MSW (Mock Service Worker) for API mocking    │
│   • Test a data-fetching component end-to-end           │
│   • Test error and loading states                       │
├─────────────────────────────────────────────────────────┤
│ DAY 3: E2E & CI                                         │
│   • Write one Cypress test for login → dashboard flow   │
│   • Set up GitHub Actions to run tests on push          │
│   • Celebrate green checkmarks ✅                       │
└─────────────────────────────────────────────────────────┘

What to Test (Priority Order)

AI-Assisted Development Protocol

📝 Sprint Deliverables

• 5+ unit tests for utilities and pure functions
• 3+ component tests using RTL
• MSW setup for mocking API in tests
• 1 Cypress E2E test for critical flow
• GitHub Actions workflow running tests on push
• Test coverage report (aim for 60%+ on core code)
• Reflection: What did tests reveal about your code?

💡 Test Examples

Unit Test (Vitest)

// src/utils/formatPrice.test.js
import { formatPrice } from './formatPrice';

describe('formatPrice', () => {
  it('formats whole numbers', () => {
    expect(formatPrice(1000)).toBe('$10.00');
  });

  it('handles zero', () => {
    expect(formatPrice(0)).toBe('$0.00');
  });
});

Component Test (RTL)

// src/components/LoginForm.test.jsx
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { LoginForm } from './LoginForm';

test('submits email and password', async () => {
  const handleSubmit = vi.fn();
  render(<LoginForm onSubmit={handleSubmit} />);

  await userEvent.type(screen.getByLabelText(/email/i), 'test@example.com');
  await userEvent.type(screen.getByLabelText(/password/i), 'password123');
  await userEvent.click(screen.getByRole('button', { name: /login/i }));

  expect(handleSubmit).toHaveBeenCalledWith({
    email: 'test@example.com',
    password: 'password123'
  });
});

🔗 Lesson Navigation

📚 Key Concepts Preview

What “good testing” means (in this course)

• Tests are a change-enabler: the goal is confidence to refactor, not “100% coverage”.
• Prefer integration tests for user-visible behavior (forms, flows, navigation).
• Unit test pure logic (reducers, validators, formatters).
• Avoid brittle tests (testing implementation details, internal state, DOM structure).

Minimal stack (recommended)

• Unit / component: Vitest + React Testing Library
• Network mocking: MSW (Mock Service Worker)
• E2E smoke (optional): Cypress (or Playwright if you already know it)

Example: test behavior, not structure

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

it('submits the form with user input', async () => {
  const user = userEvent.setup();
  const onSubmit = vi.fn();
  render(<LoginForm onSubmit={onSubmit} />);

  await user.type(screen.getByLabelText(/email/i), 'test@example.com');
  await user.type(screen.getByLabelText(/password/i), 'password123');
  await user.click(screen.getByRole('button', { name: /login/i }));

  expect(onSubmit).toHaveBeenCalledWith({ email: 'test@example.com', password: 'password123' });
});

Reflection (Atelier)

💭 Which bug did your tests prevent—specifically? What changed in your code because tests existed?

💭 Which test became too hard to write? What does that reveal about your architecture?

Koan

“If your tests require lies, your design is already lying.”

“Write tests. Not too many. Mostly integration.” — Guillermo Rauch