152 lines
6.8 KiB
Markdown
152 lines
6.8 KiB
Markdown
# Profile Integration Tests
|
|
|
|
This directory contains integration tests for the GridPilot profile functionality.
|
|
|
|
## Test Coverage
|
|
|
|
### 1. Profile Main (`profile-main-use-cases.integration.test.ts`)
|
|
Tests the orchestration logic of profile-related Use Cases:
|
|
|
|
**Use Cases Tested:**
|
|
- `GetProfileUseCase`: Retrieves driver's profile information
|
|
- `GetProfileStatisticsUseCase`: Retrieves driver's statistics and achievements
|
|
- `GetProfileCompletionUseCase`: Calculates profile completion percentage
|
|
- `UpdateProfileUseCase`: Updates driver's profile information
|
|
|
|
**Test Scenarios:**
|
|
- Driver profile retrieval with complete information
|
|
- Driver profile retrieval with minimal information
|
|
- Driver profile retrieval with avatar, social links, team affiliation
|
|
- Driver statistics calculation (win percentage, podium rate, trends)
|
|
- Profile completion calculation with suggestions
|
|
- Profile updates with validation
|
|
- Error handling for non-existent drivers and invalid inputs
|
|
|
|
### 2. Profile Leagues (`profile-leagues-use-cases.integration.test.ts`)
|
|
Tests the orchestration logic of profile leagues-related Use Cases:
|
|
|
|
**Use Cases Tested:**
|
|
- `GetProfileLeaguesUseCase`: Retrieves driver's league memberships
|
|
- `LeaveLeagueUseCase`: Allows driver to leave a league from profile
|
|
- `GetLeagueDetailsUseCase`: Retrieves league details from profile
|
|
|
|
**Test Scenarios:**
|
|
- League membership retrieval with complete information
|
|
- League membership retrieval with upcoming races, status, member count
|
|
- League membership retrieval with different roles (Member/Admin/Owner)
|
|
- League membership retrieval with category tags, rating, prize pool
|
|
- League membership retrieval with sponsor count, race count, championship count
|
|
- League membership retrieval with visibility, creation date, owner information
|
|
- Leaving league with validation
|
|
- League details retrieval
|
|
- Error handling for non-existent drivers, leagues, and invalid inputs
|
|
|
|
### 3. Profile Liveries (`profile-liveries-use-cases.integration.test.ts`)
|
|
Tests the orchestration logic of profile liveries-related Use Cases:
|
|
|
|
**Use Cases Tested:**
|
|
- `GetProfileLiveriesUseCase`: Retrieves driver's uploaded liveries
|
|
- `GetLiveryDetailsUseCase`: Retrieves livery details
|
|
- `DeleteLiveryUseCase`: Deletes a livery
|
|
|
|
**Test Scenarios:**
|
|
- Livery retrieval with complete information
|
|
- Livery retrieval with validation status (Validated/Pending)
|
|
- Livery retrieval with upload date, car name, car ID
|
|
- Livery retrieval with preview, file metadata, file size, file format
|
|
- Livery retrieval with error state
|
|
- Livery details retrieval
|
|
- Livery deletion with validation
|
|
- Error handling for non-existent drivers, liveries, and invalid inputs
|
|
|
|
### 4. Profile Settings (`profile-settings-use-cases.integration.test.ts`)
|
|
Tests the orchestration logic of profile settings-related Use Cases:
|
|
|
|
**Use Cases Tested:**
|
|
- `GetProfileSettingsUseCase`: Retrieves driver's current profile settings
|
|
- `UpdateProfileSettingsUseCase`: Updates driver's profile settings
|
|
- `UpdateAvatarUseCase`: Updates driver's avatar
|
|
- `ClearAvatarUseCase`: Clears driver's avatar
|
|
|
|
**Test Scenarios:**
|
|
- Profile settings retrieval with complete information
|
|
- Profile settings retrieval with avatar, social links, team affiliation
|
|
- Profile settings retrieval with notification preferences, privacy settings
|
|
- Profile settings updates with validation (email format, required fields)
|
|
- Avatar updates with validation (file format, size limit)
|
|
- Avatar clearing
|
|
- Error handling for non-existent drivers and invalid inputs
|
|
|
|
### 5. Profile Sponsorship Requests (`profile-sponsorship-requests-use-cases.integration.test.ts`)
|
|
Tests the orchestration logic of profile sponsorship requests-related Use Cases:
|
|
|
|
**Use Cases Tested:**
|
|
- `GetProfileSponsorshipRequestsUseCase`: Retrieves driver's sponsorship requests
|
|
- `GetSponsorshipRequestDetailsUseCase`: Retrieves sponsorship request details
|
|
- `AcceptSponsorshipRequestUseCase`: Accepts a sponsorship offer
|
|
- `RejectSponsorshipRequestUseCase`: Rejects a sponsorship offer
|
|
|
|
**Test Scenarios:**
|
|
- Sponsorship request retrieval with complete information
|
|
- Sponsorship request retrieval with sponsor information, offer terms, duration
|
|
- Sponsorship request retrieval with financial details, requirements
|
|
- Sponsorship request retrieval with status (Pending/Accepted/Rejected)
|
|
- Sponsorship request retrieval with expiration date, creation date
|
|
- Sponsorship request retrieval with revenue tracking
|
|
- Sponsorship request details retrieval
|
|
- Accepting sponsorship with validation
|
|
- Rejecting sponsorship with validation
|
|
- Error handling for non-existent drivers, sponsorship requests, and invalid inputs
|
|
|
|
## Test Philosophy
|
|
|
|
These tests follow the clean integration testing concept defined in `plans/clean_integration_strategy.md`:
|
|
|
|
1. **Focus on Use Case Orchestration**: Tests validate the interaction between Use Cases and their Ports (Repositories, Event Publishers), not UI rendering.
|
|
|
|
2. **In-Memory Adapters**: Tests use In-Memory adapters for speed and determinism, avoiding external dependencies.
|
|
|
|
3. **Business Logic Only**: Tests focus on business logic orchestration, not UI implementation details.
|
|
|
|
4. **Given/When/Then Structure**: Tests use BDD-style Given/When/Then structure in comments for clarity.
|
|
|
|
5. **Zero Implementation**: Test files are placeholders with TODO comments, focusing on test structure and scenarios.
|
|
|
|
## Implementation Notes
|
|
|
|
- All test files are placeholders with TODO comments.
|
|
- Tests should be implemented using Vitest.
|
|
- In-Memory adapters should be used for repositories and event publishers.
|
|
- Tests should validate Use Case orchestration, not implementation details.
|
|
- Tests should be independent and can run in any order.
|
|
- Tests should cover success paths, edge cases, and error handling.
|
|
|
|
## Directory Structure
|
|
|
|
```
|
|
tests/integration/profile/
|
|
├── profile-main-use-cases.integration.test.ts
|
|
├── profile-leagues-use-cases.integration.test.ts
|
|
├── profile-liveries-use-cases.integration.test.ts
|
|
├── profile-settings-use-cases.integration.test.ts
|
|
├── profile-sponsorship-requests-use-cases.integration.test.ts
|
|
└── README.md
|
|
```
|
|
|
|
## Relationship to BDD E2E Tests
|
|
|
|
These integration tests complement the BDD E2E tests in `tests/e2e/bdd/profile/`:
|
|
|
|
- **BDD E2E Tests**: Validate final user outcomes and UI behavior
|
|
- **Integration Tests**: Validate business logic orchestration and Use Case interactions
|
|
|
|
The integration tests provide fast, deterministic feedback on business logic before UI implementation, following the "Use Case First" integration strategy.
|
|
|
|
## Next Steps
|
|
|
|
1. Implement the actual Use Cases and Ports defined in the test imports
|
|
2. Create In-Memory adapter implementations for repositories and event publishers
|
|
3. Implement the integration tests by filling in the TODO comments
|
|
4. Run the tests to verify Use Case orchestration
|
|
5. Use the test results to guide Use Case implementation
|