# Rating BDD E2E Tests

This directory contains BDD (Behavior-Driven Development) E2E tests for the GridPilot Rating system.

## Overview

The GridPilot Rating system is a competition rating designed specifically for league racing. Unlike iRating (which is for matchmaking), GridPilot Rating measures:
- **Results Strength**: How well you finish relative to field strength
- **Consistency**: Stability of finishing positions over a season
- **Clean Driving**: Incidents per race, weighted by severity
- **Racecraft**: Positions gained/lost vs. incident involvement
- **Reliability**: Attendance, DNS/DNF record
- **Team Contribution**: Points earned for your team; lineup efficiency

## Test Files

### [`rating-profile.spec.ts`](rating-profile.spec.ts)
Tests the driver profile rating display, including:
- Current GridPilot Rating value
- Rating breakdown by component (results, consistency, clean driving, etc.)
- Rating trend over time (seasons)
- Rating comparison with peers
- Rating impact on team contribution

**Key Scenarios:**
- Driver sees their current GridPilot Rating on profile
- Driver sees rating breakdown by component
- Driver sees rating trend over multiple seasons
- Driver sees how rating compares to league peers
- Driver sees rating impact on team contribution
- Driver sees rating explanation/tooltip
- Driver sees rating update after race completion

### [`rating-calculation.spec.ts`](rating-calculation.spec.ts)
Tests the rating calculation logic and updates:
- Rating calculation after race completion
- Rating update based on finishing position
- Rating update based on field strength
- Rating update based on incidents
- Rating update based on consistency
- Rating update based on team contribution
- Rating update based on season performance

**Key Scenarios:**
- Rating increases after strong finish against strong field
- Rating decreases after poor finish or incidents
- Rating reflects consistency over multiple races
- Rating accounts for team contribution
- Rating updates immediately after results are processed
- Rating calculation is transparent and understandable

### [`rating-leaderboard.spec.ts`](rating-leaderboard.spec.ts)
Tests the rating-based leaderboards:
- Global driver rankings by GridPilot Rating
- League-specific driver rankings
- Team rankings based on driver ratings
- Rating-based filtering and sorting
- Rating-based search functionality

**Key Scenarios:**
- User sees drivers ranked by GridPilot Rating
- User can filter drivers by rating range
- User can search for drivers by rating
- User can sort drivers by different rating components
- User sees team rankings based on driver ratings
- User sees rating-based leaderboards with accurate data

## Test Structure

Each test file follows this pattern:

```typescript
import { test, expect } from '@playwright/test';

test.describe('GridPilot Rating System', () => {
  test.beforeEach(async ({ page }) => {
    // TODO: Implement authentication setup
  });

  test('Driver sees their GridPilot Rating on profile', async ({ page }) => {
    // TODO: Implement test
    // Scenario: Driver views their rating
    // Given I am a registered driver "John Doe"
    // And I have completed several races
    // And I am on my profile page
    // Then I should see my GridPilot Rating
    // And I should see the rating breakdown
  });
});
```

## Test Philosophy

These tests follow the BDD E2E testing concept:

- **Focus on outcomes, not visual implementation**: Tests validate what the user sees and can verify, not how it's rendered
- **Use Gherkin syntax**: Tests are written in Given/When/Then format
- **Validate final user outcomes**: Tests serve as acceptance criteria for the rating functionality
- **Use Playwright**: Tests are implemented using Playwright for browser automation

## TODO Implementation

All tests are currently placeholders with TODO comments. The actual test implementation should:

1. Set up authentication (login as a test driver)
2. Navigate to the appropriate page
3. Verify the expected outcomes using Playwright assertions
4. Handle loading states, error states, and edge cases
5. Use test data that matches the expected behavior

## Test Data

Tests should use realistic test data that matches the expected behavior:
- Driver: "John Doe" or similar test driver with varying performance
- Races: Completed races with different results (wins, podiums, DNFs)
- Fields: Races with varying field strength (strong vs. weak fields)
- Incidents: Races with different incident counts
- Teams: Teams with multiple drivers contributing to team score

## Future Enhancements

- Add test data factories/fixtures for consistent test data
- Add helper functions for common actions (login, navigation, etc.)
- Add visual regression tests for rating display
- Add performance tests for rating calculation
- Add accessibility tests for rating pages
- Add cross-browser compatibility testing