## Context

The RacePlanner project is a full-stack application with:
- **Backend**: .NET API (Controllers, Services, Data layer)
- **Frontend**: Next.js with React, TypeScript
- **Current State**: No existing test infrastructure

## Goals / Non-Goals

**Goals:**
- Establish unit testing for backend (.NET xUnit) covering Controllers, Services, and Data layer
- Establish unit testing for frontend (Jest/React Testing Library) covering components and hooks
- Create integration tests that verify frontend-backend API communication
- Set up CI/CD automation to run tests on pull requests
- Configure test runners with unified npm scripts

**Non-Goals:**
- End-to-end browser testing with Cypress/Playwright (out of scope, focus on API integration)
- Code coverage enforcement thresholds (can be added later)
- Performance/load testing

## Decisions

### Backend Testing Framework: xUnit
**Rationale**: xUnit is the modern standard for .NET testing, preferred over MSTest and NUnit. It has excellent async support, clean attribute syntax, and integrates well with .NET tooling.

**Alternatives considered**: NUnit (mature but verbose), MSTest (limited features)

### Frontend Testing Framework: Jest + React Testing Library
**Rationale**: Jest is the standard for JavaScript testing with excellent mocking and snapshot capabilities. React Testing Library provides the recommended way to test React components by focusing on user interactions rather than implementation details.

**Alternatives considered**: Vitest (faster but Next.js has better Jest integration), Cypress Component Testing (overkill for unit tests)

### Integration Test Strategy: Supertest + Playwright
**Rationale**: Use Supertest for backend API integration testing and Playwright for frontend-backend integration. This provides confidence that the frontend can successfully communicate with the backend.

### Test Organization
- Tests colocated with source files using `.test.ts` or `.spec.ts` suffix
- Separate test projects for backend (xUnit convention)
- Integration tests in dedicated directory to avoid confusion with unit tests

## Risks / Trade-offs

**[Risk] Test maintenance overhead** → Mitigation: Keep tests focused on behavior, not implementation; refactor aggressively

**[Risk] Slow CI builds** → Mitigation: Parallel test execution, selective test running based on changed files

**[Risk] Flaky integration tests** → Mitigation: Use test database, proper setup/teardown, avoid external dependencies

## Migration Plan

1. Create backend test project and add sample tests for existing controllers
2. Configure Jest in frontend and add component tests
3. Set up integration test infrastructure with docker-compose for test database
4. Add GitHub Actions workflow
5. Run full test suite to verify setup

## Open Questions

- Should we use an in-memory database for backend integration tests?
- What mock data strategy should be used for consistent test runs?
