MasterMito/raceplanner
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add comprehensive test suite infrastructure

Browse Source 
- Create backend xUnit test project with Moq and FluentAssertions
- Add test utilities: TestDataFactory, MockHttpContext, TestUserClaims
- Create AuthControllerTests with comprehensive auth scenarios
- Install Jest and React Testing Library for frontend
- Configure jest.config.ts and jest.setup.ts with Next.js support
- Add test scripts to package.json
This commit is contained in:
Denis Urs Rudolph
2026-04-05 22:16:44 +02:00
parent 32bfbcadb1
commit 571fe5bc7c
19 changed files with 11224 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/add-tests/.openspec.yaml
+2
View File
@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-04-05
openspec/changes/add-tests/design.md
+61
View File
@@ -0,0 +1,61 @@
## 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?
openspec/changes/add-tests/proposal.md
+31
View File
@@ -0,0 +1,31 @@
## Why
The RacePlanner project currently lacks a comprehensive test suite, making it difficult to ensure code quality and prevent regressions. We need to establish testing infrastructure for both the .NET backend and Next.js frontend to enable confident development and deployments.
## What Changes
- **Backend Unit Tests**: Create a .NET test project with xUnit for unit testing Controllers, Services, and Data layer
- **Frontend Unit Tests**: Set up Jest/React Testing Library for React components and hooks
- **Integration Tests**: Create end-to-end integration tests that verify frontend-backend communication via API calls
- **Test Automation**: Configure test runners with npm scripts for automated execution
- **CI/CD Integration**: Add GitHub Actions workflow to run tests on pull requests
## Capabilities
### New Capabilities
- `backend-unit-tests`: .NET xUnit test project for API Controllers, Services, and Data layer
- `frontend-unit-tests`: Jest/React Testing Library setup for Next.js components and hooks
- `integration-tests`: End-to-end tests verifying API communication between frontend and backend
- `test-automation`: Automated test runners and CI/CD integration
### Modified Capabilities
- None (this change adds testing infrastructure without modifying existing functionality)
## Impact
- **Backend**: New `backend.Tests/` project directory added, new test dependencies in `.csproj`
- **Frontend**: Additional dev dependencies for Jest and React Testing Library
- **CI/CD**: New GitHub Actions workflow in `.github/workflows/` for automated testing
- **Build Process**: New npm scripts (`test`, `test:backend`, `test:frontend`, `test:integration`) added
openspec/changes/add-tests/specs/backend-unit-tests/spec.md
+37
View File
@@ -0,0 +1,37 @@
## ADDED Requirements
### Requirement: Backend test project exists
The system SHALL have a dedicated .NET test project named `backend.Tests` that references the main `backend` project.
#### Scenario: Test project references main project
- **WHEN** the test project is built
- **THEN** it SHALL have a project reference to the main backend API project
### Requirement: Controllers can be unit tested
The system SHALL provide the ability to unit test API Controllers with mocked dependencies.
#### Scenario: Controller with mocked service
- **WHEN** a controller action is invoked with a mocked service
- **THEN** the test SHALL verify the correct HTTP response is returned
#### Scenario: Controller input validation
- **WHEN** invalid input is passed to a controller action
- **THEN** the test SHALL verify validation errors are returned
### Requirement: Services can be unit tested
The system SHALL provide the ability to unit test business logic in Services with mocked dependencies.
#### Scenario: Service with mocked repository
- **WHEN** a service method is called with a mocked data repository
- **THEN** the test SHALL verify the expected business logic is executed
### Requirement: Test utilities are available
The system SHALL provide common test utilities for setup, teardown, and assertions.
#### Scenario: Mock data factories
- **WHEN** tests require test data
- **THEN** factory classes SHALL generate consistent mock entities
#### Scenario: HTTP context mocking
- **WHEN** tests need to simulate HTTP requests
- **THEN** utilities SHALL provide mocked HttpContext and User claims
openspec/changes/add-tests/specs/frontend-unit-tests/spec.md
+49
View File
@@ -0,0 +1,49 @@
## ADDED Requirements
### Requirement: Jest is configured
The system SHALL have Jest configured for the Next.js frontend with TypeScript support.
#### Scenario: Jest runs TypeScript tests
- **WHEN** a test file with `.test.ts` or `.test.tsx` extension is executed
- **THEN** Jest SHALL compile and run TypeScript tests successfully
#### Scenario: Jest runs in Next.js environment
- **WHEN** tests import Next.js modules or use Next.js APIs
- **THEN** the test environment SHALL provide necessary Next.js mocks and configuration
### Requirement: React Testing Library is configured
The system SHALL have React Testing Library configured for component testing.
#### Scenario: Components can be rendered in tests
- **WHEN** a React component is rendered using render() from RTL
- **THEN** the component SHALL render in a virtual DOM for testing
#### Scenario: User interactions can be simulated
- **WHEN** test code uses userEvent or fireEvent
- **THEN** user interactions SHALL be simulated on rendered components
### Requirement: Custom hooks can be tested
The system SHALL provide utilities for testing custom React hooks.
#### Scenario: Hook can be tested with renderHook
- **WHEN** a custom hook is tested using renderHook utility
- **THEN** the hook SHALL execute and return values can be asserted
#### Scenario: Hook state changes can be awaited
- **WHEN** a hook performs async operations
- **THEN** the test SHALL be able to wait for state updates with waitFor utility
### Requirement: API mocking is available
The system SHALL provide utilities for mocking HTTP requests in frontend tests.
#### Scenario: API calls can be mocked
- **WHEN** components make HTTP requests using fetch or axios
- **THEN** the test SHALL be able to mock responses using MSW or jest-fetch-mock
#### Scenario: Loading states can be tested
- **WHEN** components are fetching data
- **THEN** the test SHALL verify loading states are rendered correctly
#### Scenario: Error states can be tested
- **WHEN** API calls fail
- **THEN** the test SHALL verify error handling and error messages
openspec/changes/add-tests/specs/integration-tests/spec.md
+49
View File
@@ -0,0 +1,49 @@
## ADDED Requirements
### Requirement: Backend API integration tests exist
The system SHALL have integration tests for the backend API that verify endpoints work correctly with real or test database.
#### Scenario: API endpoint returns expected response
- **WHEN** an API endpoint is called via HTTP request
- **THEN** the response SHALL match expected status code and body structure
#### Scenario: API endpoint persists data
- **WHEN** a POST or PUT request is made
- **THEN** the data SHALL be persisted and retrievable via GET request
#### Scenario: API handles authentication
- **WHEN** a protected endpoint is called with or without valid authentication
- **THEN** the response SHALL enforce authentication rules correctly
### Requirement: Frontend-backend integration tests exist
The system SHALL have tests that verify the frontend can communicate with the backend API.
#### Scenario: Frontend fetches data from backend
- **WHEN** the frontend makes an API call to the backend
- **THEN** the backend SHALL receive the request and return appropriate data
#### Scenario: Frontend sends data to backend
- **WHEN** the frontend submits form data to the backend
- **THEN** the backend SHALL process the data and return success or error response
### Requirement: Test database is isolated
The system SHALL use an isolated test database for integration tests.
#### Scenario: Test database is separate from development database
- **WHEN** integration tests run
- **THEN** they SHALL connect to a test database, not the development database
#### Scenario: Test database is reset between test runs
- **WHEN** integration tests complete
- **THEN** the test database state SHALL be cleaned up to ensure test isolation
### Requirement: Integration tests can run in CI
The system SHALL support running integration tests in CI environment with test infrastructure.
#### Scenario: Backend and database start for tests
- **WHEN** integration tests are executed in CI
- **THEN** the backend and test database SHALL start automatically before tests
#### Scenario: Tests use correct environment configuration
- **WHEN** tests run in CI environment
- **THEN** they SHALL use CI-specific configuration (test database URLs, test auth secrets)
openspec/changes/add-tests/specs/test-automation/spec.md
+58
View File
@@ -0,0 +1,58 @@
## ADDED Requirements
### Requirement: NPM scripts exist for test execution
The system SHALL provide npm scripts to run different test suites.
#### Scenario: Run all tests
- **WHEN** the command `npm test` or `npm run test` is executed
- **THEN** all unit and integration tests SHALL execute
#### Scenario: Run backend tests only
- **WHEN** the command `npm run test:backend` is executed
- **THEN** only the backend unit tests SHALL run
#### Scenario: Run frontend tests only
- **WHEN** the command `npm run test:frontend` is executed
- **THEN** only the frontend unit tests SHALL run
#### Scenario: Run integration tests only
- **WHEN** the command `npm run test:integration` is executed
- **THEN** only the integration tests SHALL run
### Requirement: Tests run in watch mode for development
The system SHALL support watch mode for iterative development.
#### Scenario: Watch mode runs tests on file changes
- **WHEN** the command `npm run test:watch` is executed
- **THEN** tests SHALL re-run automatically when source or test files change
#### Scenario: Watch mode can filter by test pattern
- **WHEN** a test pattern is specified (e.g., `npm run test:watch -- Auth`)
- **THEN** only matching tests SHALL run in watch mode
### Requirement: Gitea Actions workflow exists
The system SHALL have a Gitea Actions workflow that runs tests on pull requests.
#### Scenario: Tests run on PR creation
- **WHEN** a pull request is opened
- **THEN** the Gitea Actions workflow SHALL trigger and run all tests
#### Scenario: Tests run on PR update
- **WHEN** new commits are pushed to an open pull request
- **THEN** the Gitea Actions workflow SHALL re-run tests
#### Scenario: PR is blocked on test failure
- **WHEN** tests fail in the PR
- **THEN** the PR SHALL show failed status and optionally block merging
#### Scenario: Backend tests run in CI
- **WHEN** the CI workflow executes
- **THEN** backend unit tests SHALL run after the project builds successfully
#### Scenario: Frontend tests run in CI
- **WHEN** the CI workflow executes
- **THEN** frontend unit tests SHALL run after dependencies are installed
#### Scenario: Integration tests run in CI
- **WHEN** the CI workflow executes
- **THEN** integration tests SHALL run with test infrastructure (backend + database) available
openspec/changes/add-tests/tasks.md
+300
View File
@@ -0,0 +1,300 @@
## 1. Backend Unit Tests
### 1.1 Create Backend Test Project
- [ ] 1.1.1 Create new .NET test project `backend.Tests/` with `dotnet new xunit`
- [ ] 1.1.2 Add project reference from `backend.Tests` to main `backend` project
- [ ] 1.1.3 Add test dependencies: `Moq` or `NSubstitute` for mocking, `FluentAssertions` for assertions
- [ ] 1.1.4 Configure test project settings in `backend.Tests.csproj`
- [ ] 1.1.5 Add `.gitignore` entries for test artifacts (bin, obj, coverage reports)
### 1.2 Create Test Utilities
- [ ] 1.2.1 Create `TestDataFactory` class for generating mock entities
- [ ] 1.2.2 Create `MockHttpContext` utility for simulating HTTP requests
- [ ] 1.2.3 Create `TestUserClaims` utility for mocking authenticated users
- [ ] 1.2.4 Add shared test fixtures in `SharedTestCollection` or base test class
### 1.3 Add Sample Controller Tests
- [ ] 1.3.1 Identify existing controllers in `backend/Controllers/`
- [ ] 1.3.2 Create first controller test file (e.g., `AuthControllerTests.cs`)
- [ ] 1.3.3 Write tests for controller action with mocked service
- [ ] 1.3.4 Write tests for controller input validation
- [ ] 1.3.5 Verify all tests pass with `dotnet test`
### 1.4 Add Sample Service Tests
- [ ] 1.4.1 Identify existing services in `backend/Services/`
- [ ] 1.4.2 Create first service test file (e.g., `UserServiceTests.cs`)
- [ ] 1.4.3 Write tests for service method with mocked repository
- [ ] 1.4.4 Write tests for service business logic scenarios
- [ ] 1.4.5 Verify all tests pass with `dotnet test`
## 2. Frontend Unit Tests
### 2.1 Configure Jest for Next.js
- [ ] 2.1.1 Install Jest and related dependencies: `jest`, `@testing-library/jest-dom`, `ts-jest`, `@types/jest`
- [ ] 2.1.2 Create `jest.config.ts` with Next.js and TypeScript configuration
- [ ] 2.1.3 Add `jest.setup.ts` for test environment setup
- [ ] 2.1.4 Update `package.json` with test scripts
- [ ] 2.1.5 Configure TypeScript paths if needed in `tsconfig.json`
### 2.2 Configure React Testing Library
- [ ] 2.2.1 Install RTL dependencies: `@testing-library/react`, `@testing-library/user-event`, `@testing-library/dom`
- [ ] 2.2.2 Create `test-utils.tsx` with custom render function and providers
- [ ] 2.2.3 Add Next.js router mock in test utilities
- [ ] 2.2.4 Configure automatic cleanup in `jest.setup.ts`
### 2.3 Add Sample Component Tests
- [ ] 2.3.1 Create first component test file (e.g., `Button.test.tsx`)
- [ ] 2.3.2 Write test for component rendering
- [ ] 2.3.3 Write test for user interactions (click, input, etc.)
- [ ] 2.3.4 Write test for component props and state
- [ ] 2.3.5 Verify all tests pass with `npm test`
### 2.4 Add Sample Hook Tests
- [ ] 2.4.1 Create first hook test file (e.g., `useAuth.test.ts`)
- [ ] 2.4.2 Write test using `renderHook` from `@testing-library/react`
- [ ] 2.4.3 Write test for async hook operations with `waitFor`
- [ ] 2.4.4 Write test for hook state changes
- [ ] 2.4.5 Verify all tests pass with `npm test`
### 2.5 Configure API Mocking
- [ ] 2.5.1 Install MSW (Mock Service Worker): `msw`, `@mswjs/data` (optional)
- [ ] 2.5.2 Create MSW server setup in `src/mocks/server.ts`
- [ ] 2.5.3 Create API handlers for common endpoints
- [ ] 2.5.4 Integrate MSW with Jest setup
- [ ] 2.5.5 Write test verifying API mocking works correctly
## 3. Integration Tests
### 3.1 Create Integration Test Directory Structure
- [ ] 3.1.1 Create `/tests` directory at project root
- [ ] 3.1.2 Create `/tests/integration` subdirectory
- [ ] 3.1.3 Create `/tests/integration/backend` for backend API tests
- [ ] 3.1.4 Create `/tests/integration/e2e` for frontend-backend tests
- [ ] 3.1.5 Add `.gitignore` entries for integration test artifacts
### 3.2 Backend Integration Test Setup
- [ ] 3.2.1 Install Supertest: `npm install --save-dev supertest @types/supertest`
- [ ] 3.2.2 Create `TestWebApplicationFactory` for ASP.NET Core integration tests
- [ ] 3.2.3 Configure test database connection (SQLite in-memory or test Postgres)
- [ ] 3.2.4 Create database seeding utilities for test data
- [ ] 3.2.5 Add first integration test file (e.g., `AuthApiTests.cs`)
### 3.3 Write Backend Integration Tests
- [ ] 3.3.1 Write test for GET endpoint returning expected data
- [ ] 3.3.2 Write test for POST endpoint persisting data
- [ ] 3.3.3 Write test for PUT endpoint updating data
- [ ] 3.3.4 Write test for DELETE endpoint removing data
- [ ] 3.3.5 Write test for authentication/authorization on protected endpoints
- [ ] 3.3.6 Verify backend integration tests pass
### 3.4 Frontend-Backend Integration Test Setup
- [ ] 3.4.1 Install Playwright: `npm install --save-dev @playwright/test`
- [ ] 3.4.2 Initialize Playwright: `npx playwright install`
- [ ] 3.4.3 Create `playwright.config.ts` with test configuration
- [ ] 3.4.4 Create `global-setup.ts` for starting backend before tests
- [ ] 3.4.5 Create `global-teardown.ts` for cleanup after tests
### 3.5 Write Frontend-Backend Integration Tests
- [ ] 3.5.1 Create first E2E test file (e.g., `auth.spec.ts`)
- [ ] 3.5.2 Write test for frontend fetching data from backend
- [ ] 3.5.3 Write test for frontend submitting form to backend
- [ ] 3.5.4 Write test for error handling between frontend and backend
- [ ] 3.5.5 Verify E2E tests pass with `npx playwright test`
## 4. Feature-Based Test Cases (From Archived Specs)
Based on the archived RacePlanner specifications, implement comprehensive test coverage:
### 4.0.1 User Authentication Tests
**From specs/user-auth/spec.md:**
- [ ] 4.0.1.1 **Registration - Positive**: Test successful registration with valid email and password
- [ ] 4.0.1.2 **Registration - Negative**: Test registration with duplicate email returns error
- [ ] 4.0.1.3 **Registration - Negative**: Test registration with invalid email format returns validation error
- [ ] 4.0.1.4 **Registration - Negative**: Test registration with weak password returns validation error
- [ ] 4.0.1.5 **Registration - Negative**: Test registration with mismatched password confirmation returns error
- [ ] 4.0.1.6 **Login - Positive**: Test successful login with correct credentials
- [ ] 4.0.1.7 **Login - Negative**: Test login with incorrect password returns error
- [ ] 4.0.1.8 **Login - Negative**: Test login with non-existent email returns error
- [ ] 4.0.1.9 **Login - Negative**: Test login with empty credentials returns validation error
- [ ] 4.0.1.10 **Role Access - Positive**: Test organizer role can access full event CRUD operations
- [ ] 4.0.1.11 **Role Access - Negative**: Test participant role cannot modify events (read-only)
- [ ] 4.0.1.12 **Role Access - Negative**: Test unauthenticated user cannot access protected routes
### 4.0.2 Event Management Tests
**From specs/event-management/spec.md:**
- [ ] 4.0.2.1 **Create Event - Positive**: Test creating event with all required fields
- [ ] 4.0.2.2 **Create Event - Negative**: Test creating event without name returns validation error
- [ ] 4.0.2.3 **Create Event - Negative**: Test creating event with invalid date format returns error
- [ ] 4.0.2.4 **Create Event - Negative**: Test creating event with past date returns validation error
- [ ] 4.0.2.5 **Edit Event - Positive**: Test updating event date notifies registered participants
- [ ] 4.0.2.6 **Edit Event - Negative**: Test editing non-existent event returns 404
- [ ] 4.0.2.7 **Edit Event - Negative**: Test editing event without permission returns 403
- [ ] 4.0.2.8 **Publish Event - Positive**: Test publishing draft event changes status to "published"
- [ ] 4.0.2.9 **Publish Event - Negative**: Test publishing already published event returns appropriate response
- [ ] 4.0.2.10 **List Events - Positive**: Test retrieving upcoming events sorted by date
- [ ] 4.0.2.11 **List Events - Positive**: Test filtering events by specific organizer
- [ ] 4.0.2.12 **List Events - Negative**: Test filtering with invalid organizer ID returns empty list
### 4.0.3 Event Categorization Tests
**From specs/event-categorization/spec.md:**
- [ ] 4.0.3.1 **Assign Category - Positive**: Test assigning category on event creation
- [ ] 4.0.3.2 **Assign Category - Positive**: Test assigning category to existing event
- [ ] 4.0.3.3 **Assign Category - Negative**: Test assigning invalid category returns validation error
- [ ] 4.0.3.4 **Clear Category - Positive**: Test removing category from event
- [ ] 4.0.3.5 **Tags - Positive**: Test adding multiple tags on event creation
- [ ] 4.0.3.6 **Tags - Positive**: Test modifying tags on existing event
- [ ] 4.0.3.7 **Tags - Negative**: Test adding duplicate tags (should handle gracefully)
- [ ] 4.0.3.8 **Filter by Category - Positive**: Test filtering events by single category
- [ ] 4.0.3.9 **Filter by Category - Negative**: Test filtering by non-existent category returns empty list
- [ ] 4.0.3.10 **Filter by Tag - Positive**: Test filtering events by single tag
- [ ] 4.0.3.11 **Filter by Tag - Positive**: Test filtering events by multiple tags (ANY match)
- [ ] 4.0.3.12 **Category Management - Positive**: Test retrieving predefined category list
### 4.0.4 Registration System Tests
**From specs/registration-system/spec.md:**
- [ ] 4.0.4.1 **Registration - Positive**: Test successful registration for published event
- [ ] 4.0.4.2 **Registration - Negative**: Test registration for full event returns error
- [ ] 4.0.4.3 **Registration - Negative**: Test duplicate registration returns "Already registered" error
- [ ] 4.0.4.4 **Registration - Negative**: Test registration for unpublished event returns error
- [ ] 4.0.4.5 **Registration - Negative**: Test registration without authentication returns 401
- [ ] 4.0.4.6 **Registration Form - Positive**: Test collecting participant details (name, email, emergency contact, category)
- [ ] 4.0.4.7 **Registration Form - Negative**: Test submitting incomplete form returns validation errors
- [ ] 4.0.4.8 **Registration Form - Negative**: Test invalid email format in registration returns error
- [ ] 4.0.4.9 **Registration Status - Positive**: Test viewing registration status (pending, confirmed, cancelled, completed)
- [ ] 4.0.4.10 **Cancel Registration - Positive**: Test cancelling registration updates status and releases spot
- [ ] 4.0.4.11 **Cancel Registration - Negative**: Test cancelling non-existent registration returns 404
### 4.0.5 Payment Tracking Tests
**From specs/payment-tracking/spec.md:**
- [ ] 4.0.5.1 **Record Cash Payment - Positive**: Test recording cash payment updates registration status
- [ ] 4.0.5.2 **Record Online Payment - Positive**: Test recording payment with transaction ID
- [ ] 4.0.5.3 **Payment Status - Positive**: Test "unpaid" status when no payment recorded
- [ ] 4.0.5.4 **Payment Status - Positive**: Test "partial" status with remaining balance shown
- [ ] 4.0.5.5 **Payment Status - Positive**: Test "paid" status when payment equals/exceeds amount
- [ ] 4.0.5.6 **Payment Status - Negative**: Test recording negative payment amount returns error
- [ ] 4.0.5.7 **Payment Status - Negative**: Test recording payment for non-existent registration returns 404
- [ ] 4.0.5.8 **Payment Reporting - Positive**: Test generating event payment summary
- [ ] 4.0.5.9 **Payment Reporting - Negative**: Test accessing payment report without organizer role returns 403
### 4.0.6 Dashboard Tests
**From specs/dashboard/spec.md:**
- [ ] 4.0.6.1 **Organizer Dashboard - Positive**: Test displaying event statistics (total events, registrations, revenue)
- [ ] 4.0.6.2 **Organizer Dashboard - Positive**: Test displaying upcoming events list
- [ ] 4.0.6.3 **Organizer Dashboard - Positive**: Test displaying registration trends
- [ ] 4.0.6.4 **Organizer Dashboard - Positive**: Test highlighting events nearing capacity
- [ ] 4.0.6.5 **Participant Dashboard - Positive**: Test displaying user's registrations
- [ ] 4.0.6.6 **Participant Dashboard - Positive**: Test sorting upcoming events by date
- [ ] 4.0.6.7 **Quick Actions - Positive**: Test organizer quick action links (create event, view reports, send announcements)
- [ ] 4.0.6.8 **Quick Actions - Positive**: Test participant quick action links (browse events, view history)
- [ ] 4.0.6.9 **Dashboard - Negative**: Test accessing dashboard without authentication redirects to login
### 4.0.7 Announcements Tests
**From specs/announcements/spec.md:**
- [ ] 4.0.7.1 **Create Announcement - Positive**: Test creating announcement with title and content
- [ ] 4.0.7.2 **Create Announcement - Negative**: Test creating announcement without title returns validation error
- [ ] 4.0.7.3 **Create Announcement - Negative**: Test creating announcement without content returns validation error
- [ ] 4.0.7.4 **Create Announcement - Negative**: Test creating announcement without permission returns 403
- [ ] 4.0.7.5 **Announcement Visibility - Positive**: Test displaying announcements on event page sorted by newest first
- [ ] 4.0.7.6 **Notification - Positive**: Test sending notification to registered participants on new announcement
- [ ] 4.0.7.7 **Mark as Read - Positive**: Test marking notification as read when participant views announcement
- [ ] 4.0.7.8 **Edit Announcement - Positive**: Test editing existing announcement updates content and shows timestamp
- [ ] 4.0.7.9 **Edit Announcement - Negative**: Test editing non-existent announcement returns 404
- [ ] 4.0.7.10 **Delete Announcement - Positive**: Test deleting announcement removes it from event
- [ ] 4.0.7.11 **Delete Announcement - Negative**: Test deleting announcement without permission returns 403
### 4.0.8 Additional Positive Test Cases
- [ ] 4.0.8.1 **Concurrent Registration**: Test multiple users registering simultaneously for same event
- [ ] 4.0.8.2 **Pagination**: Test event listing pagination with large dataset
- [ ] 4.0.8.3 **Search**: Test searching events by name or description
- [ ] 4.0.8.4 **Sorting**: Test sorting events by date, name, and category
- [ ] 4.0.8.5 **Session Persistence**: Test user session persists across page reloads
- [ ] 4.0.8.6 **Rate Limiting**: Test API rate limiting allows reasonable usage
### 4.0.9 Additional Negative/Edge Test Cases
- [ ] 4.0.9.1 **SQL Injection**: Test input fields protect against SQL injection attacks
- [ ] 4.0.9.2 **XSS Protection**: Test output is properly escaped to prevent XSS
- [ ] 4.0.9.3 **CSRF Protection**: Test form submissions require valid CSRF tokens
- [ ] 4.0.9.4 **Long Input**: Test handling of extremely long input values
- [ ] 4.0.9.5 **Special Characters**: Test handling of special characters in input
- [ ] 4.0.9.6 **Unicode**: Test handling of Unicode characters in text fields
- [ ] 4.0.9.7 **Empty String**: Test handling of empty strings vs null values
- [ ] 4.0.9.8 **Boundary Values**: Test boundary values for numeric fields (capacity, price)
- [ ] 4.0.9.9 **Invalid IDs**: Test API endpoints with malformed UUIDs or IDs
- [ ] 4.0.9.10 **Unauthorized Access**: Test accessing resources without proper authorization
- [ ] 4.0.9.11 **Expired Session**: Test behavior with expired authentication tokens
- [ ] 4.0.9.12 **Large Payload**: Test handling of request payloads exceeding size limits
## 4. Test Automation
### 4.1 Add NPM Scripts
- [ ] 4.1.1 Add `test` script to run all tests
- [ ] 4.1.2 Add `test:backend` script to run backend unit tests (`dotnet test`)
- [ ] 4.1.3 Add `test:frontend` script to run frontend unit tests (`jest`)
- [ ] 4.1.4 Add `test:integration` script to run integration tests
- [ ] 4.1.5 Add `test:watch` script for watch mode
- [ ] 4.1.6 Add `test:coverage` script to generate coverage reports
### 4.2 Configure Test Watch Mode
- [ ] 4.2.1 Configure Jest watch mode in `jest.config.ts`
- [ ] 4.2.2 Add pattern matching support to watch mode
- [ ] 4.2.3 Verify watch mode works with `npm run test:watch`
### 4.3 Create Gitea Actions Workflow
- [ ] 4.3.1 Create `.gitea/workflows/` directory
- [ ] 4.3.2 Create `test.yml` workflow file
- [ ] 4.3.3 Configure workflow trigger on pull request events
- [ ] 4.3.4 Add job to checkout code
- [ ] 4.3.5 Add job to setup .NET SDK
- [ ] 4.3.6 Add job to setup Node.js
- [ ] 4.3.7 Add job to install backend dependencies and run backend tests
- [ ] 4.3.8 Add job to install frontend dependencies and run frontend tests
- [ ] 4.3.9 Add job to run integration tests with test infrastructure
- [ ] 4.3.10 Configure workflow to block PR merge on test failure
### 4.4 Configure Test Database for CI
- [ ] 4.4.1 Update `docker-compose.yml` to include test database service (if using Docker)
- [ ] 4.4.2 Create `appsettings.Test.json` for test configuration
- [ ] 4.4.3 Configure Gitea Actions to use test database connection string
- [ ] 4.4.4 Add database setup/teardown scripts for CI
### 4.5 Documentation and Final Verification
- [ ] 4.5.1 Update root `README.md` with testing instructions
- [ ] 4.5.2 Add `TESTING.md` with detailed test documentation
- [ ] 4.5.3 Update `AGENTS.md` with testing commands for AI agents
- [ ] 4.5.4 Run full test suite locally: `npm test`
- [ ] 4.5.5 Verify Gitea Actions workflow runs successfully (may need to push and create PR)