tdd-workflow

Test-Driven Development Workflow

This skill ensures all code development follows TDD principles with comprehensive test coverage.

When to Activate

• Writing new features or functionality
• Fixing bugs or issues
• Refactoring existing code
• Adding API endpoints
• Creating new components

Core Principles

1. Tests BEFORE Code

ALWAYS write tests first, then implement code to make tests pass.

2. Coverage Requirements

• Minimum 80% coverage (unit + integration + E2E)
• All edge cases covered
• Error scenarios tested
• Boundary conditions verified

3. Test Types

Unit Tests

• Individual functions and utilities
• Component logic
• Pure functions
• Helpers and utilities

Integration Tests

• API endpoints
• Database operations
• Service interactions
• External API calls

E2E Tests (Playwright)

• Critical user flows
• Complete workflows
• Browser automation
• UI interactions

4. Git Checkpoints

• If the repository is under Git, create a checkpoint commit after each TDD stage
• Do not squash or rewrite these checkpoint commits until the workflow is complete
• Each checkpoint commit message must describe the stage and the exact evidence captured
• Count only commits created on the current active branch for the current task
• Do not treat commits from other branches, earlier unrelated work, or distant branch history as valid checkpoint evidence
• Before treating a checkpoint as satisfied, verify that the commit is reachable from the current HEAD on the active branch and belongs to the current task sequence
• The preferred compact workflow is:
  • one commit for failing test added and RED validated
  • one commit for minimal fix applied and GREEN validated
  • one optional commit for refactor complete
• Separate evidence-only commits are not required if the test commit clearly corresponds to RED and the fix commit clearly corresponds to GREEN

TDD Workflow Steps

Step 1: Write User Journeys

As a [role], I want to [action], so that [benefit]

Example:
As a user, I want to search for items semantically,
so that I can find relevant results even without exact keywords.

Step 2: Generate Test Cases

For each user journey, create comprehensive test cases:

describe('Semantic Search', () => {
  it('returns relevant results for query', async () => {
    // Test implementation
  })

  it('handles empty query gracefully', async () => {
    // Test edge case
  })

  it('falls back to substring search when cache unavailable', async () => {
    // Test fallback behavior
  })

  it('sorts results by similarity score', async () => {
    // Test sorting logic
  })
})

Step 3: Run Tests (They Should Fail)

npm test
# Tests should fail - we haven't implemented yet

This step is mandatory and is the RED gate for all production changes.

Before modifying business logic or other production code, you must verify a valid RED state via one of these paths:

• Runtime RED:
  • The relevant test target compiles successfully
  • The new or changed test is actually executed
  • The result is RED
• Compile-time RED:
  • The new test newly instantiates, references, or exercises the buggy code path
  • The compile failure is itself the intended RED signal
• In either case, the failure is caused by the intended business-logic bug, undefined behavior, or missing implementation
• The failure is not caused only by unrelated syntax errors, broken test setup, missing dependencies, or unrelated regressions

A test that was only written but not compiled and executed does not count as RED.

Do not edit production code until this RED state is confirmed.

If the repository is under Git, create a checkpoint commit immediately after this stage is validated.

Step 4: Implement Code

Write minimal code to make tests pass:

// Implementation guided by tests
export async function searchItems(query: string) {
  // Implementation here
}

If the repository is under Git, stage the minimal fix now but defer the checkpoint commit until GREEN is validated in Step 5.

Step 5: Run Tests Again

npm test
# Tests should now pass

Rerun the same relevant test target after the fix and confirm the previously failing test is now GREEN.

Only after a valid GREEN result may you proceed to refactor.

If the repository is under Git, create a checkpoint commit immediately after GREEN is validated.

Step 6: Refactor

Improve code quality while keeping tests green:

• Remove duplication
• Improve naming
• Optimize performance
• Enhance readability

If the repository is under Git, create a checkpoint commit immediately after refactoring is complete and tests remain green.

Step 7: Verify Coverage

npm run test:coverage
# Verify 80%+ coverage achieved

Testing Patterns

Unit Test Pattern (Jest/Vitest)

import { render, screen, fireEvent } from '@testing-library/react'
import { Button } from './Button'

describe('Button Component', () => {
  it('renders with correct text', () => {
    render(<Button>Click me</Button>)
    expect(screen.getByText('Click me')).toBeInTheDocument()
  })

  it('calls onClick when clicked', () => {
    const handleClick = jest.fn()
    render(<Button onClick={handleClick}>Click</Button>)

    fireEvent.click(screen.getByRole('button'))

    expect(handleClick).toHaveBeenCalledTimes(1)
  })

  it('is disabled when disabled prop is true', () => {
    render(<Button disabled>Click</Button>)
    expect(screen.getByRole('button')).toBeDisabled()
  })
})

API Integration Test Pattern

describe('GET /api/items', () => {
  it('returns items successfully', async () => {
    const request = new Request('http://localhost/api/items')
    const response = await GET(request)
    const data = await response.json()

    expect(response.status).toBe(200)
    expect(data.success).toBe(true)
    expect(Array.isArray(data.data)).toBe(true)
  })

  it('validates query parameters', async () => {
    const request = new Request('http://localhost/api/items?limit=invalid')
    const response = await GET(request)

    expect(response.status).toBe(400)
  })

  it('handles database errors gracefully', async () => {
    // Mock database failure
    // Test error handling
  })
})

E2E Test Pattern (Playwright)

import { test, expect } from '@playwright/test'

test('user can search and filter items', async ({ page }) => {
  await page.goto('/')
  await page.click('a[href="/items"]')

  await expect(page.locator('h1')).toContainText('Items')
  await page.fill('input[placeholder="Search"]', 'test query')
  await page.waitForTimeout(600)

  const results = page.locator('[data-testid="item-card"]')
  await expect(results).toHaveCount(5, { timeout: 5000 })
})

Test File Organization

src/
├── components/
│   ├── Button/
│   │   ├── Button.tsx
│   │   ├── Button.test.tsx          # Unit tests
│   │   └── Button.stories.tsx       # Storybook
├── app/
│   └── api/
│       └── items/
│           ├── route.ts
│           └── route.test.ts         # Integration tests
└── e2e/
    ├── items.spec.ts                 # E2E tests
    └── auth.spec.ts

Common Testing Mistakes to Avoid

WRONG: Testing Implementation Details

// Don't test internal state
expect(component.state.count).toBe(5)

CORRECT: Test User-Visible Behavior

// Test what users see
expect(screen.getByText('Count: 5')).toBeInTheDocument()

WRONG: Brittle Selectors

await page.click('.css-class-xyz')

CORRECT: Semantic Selectors

await page.click('button:has-text("Submit")')
await page.click('[data-testid="submit-button"]')

WRONG: No Test Isolation

test('creates user', () => { /* ... */ })
test('updates same user', () => { /* depends on previous test */ })

CORRECT: Independent Tests

test('creates user', () => {
  const user = createTestUser()
  // Test logic
})

test('updates user', () => {
  const user = createTestUser()
  // Update logic
})

Best Practices

1. Write Tests First - Always TDD
2. One Assert Per Test - Focus on single behavior
3. Descriptive Test Names - Explain what's tested
4. Arrange-Act-Assert - Clear test structure
5. Mock External Dependencies - Isolate unit tests
6. Test Edge Cases - Null, undefined, empty, large
7. Test Error Paths - Not just happy paths
8. Keep Tests Fast - Unit tests < 50ms each
9. Clean Up After Tests - No side effects
10. Review Coverage Reports - Identify gaps

Success Metrics

• 80%+ code coverage achieved
• All tests passing (green)
• No skipped or disabled tests
• Fast test execution (< 30s for unit tests)
• E2E tests cover critical user flows
• Tests catch bugs before production

---

Remember: Tests are not optional. They are the safety net that enables confident refactoring, rapid development, and production reliability.