Overview
OpenTogetherTube uses a comprehensive testing strategy combining unit tests, component tests, and end-to-end tests to ensure code quality and prevent regressions.Testing Stack
TypeScript/JavaScript
- Unit Tests: Vitest
- Component Tests: Cypress with Vue Testing Library
- E2E Tests: Cypress
- Mocking: Vitest mocks, redis-mock
- Coverage: Vitest coverage (v8)
Rust
- Unit Tests: Built-in test framework
- Integration Tests: Harness crate
- Benchmarks: Criterion
Running Tests
All Tests
Run all tests across all workspaces:Unit Tests
Run all unit tests:Component Tests
Run component tests (Cypress):End-to-End Tests
Run E2E tests:Rust Tests
Run Rust tests:Test Coverage
Generating Coverage Reports
TypeScript:coverage/ directory of each workspace.
View HTML coverage report:
Writing Tests
Test File Organization
Naming Convention:- Unit tests:
*.spec.tsor*.test.ts - Place in
/tests/unit/directory - E2E tests:
/tests/e2e/integration/*.spec.ts
Unit Test Patterns
Basic Structure:Mocking Dependencies
Mocking Redis:Component Testing
Testing Vue Components:E2E Testing
Cypress Test Example:Rust Testing
Unit Test Example:Test Database Setup
Before running tests, initialize the test database:Continuous Integration
Pre-commit Checks
Run before committing:CI Pipeline
The GitHub Actions CI pipeline runs:- Linting (ESLint, Prettier)
- TypeScript compilation
- Unit tests with coverage
- Component tests
- E2E tests
- Rust tests and clippy
Best Practices
Test Independence
- Each test should be independent
- Use
beforeEachto set up clean state - Use
afterEachto clean up resources - Avoid shared mutable state between tests
Test Coverage Goals
- Critical Paths: 100% coverage
- Business Logic: >90% coverage
- UI Components: >80% coverage
- Utilities: >95% coverage
What to Test
Do Test:- Business logic and algorithms
- API endpoints and request validation
- Error handling and edge cases
- State management and data flow
- Critical user interactions
- Third-party library internals
- Simple getters/setters without logic
- Configuration files
- Type definitions alone
Mocking Strategy
- Mock external dependencies (APIs, databases)
- Use real implementations for internal modules when practical
- Keep mocks simple and focused
- Update mocks when APIs change
Test Performance
- Keep unit tests fast (less than 100ms each)
- Use parallel test execution
- Mock slow operations (network, file I/O)
- Use in-memory databases for tests
Debugging Tests
Debugging Vitest Tests
Debugging Cypress Tests
VSCode Debugging
Use the VSCode debugger with breakpoints:- Set breakpoints in test files
- Run “Debug: JavaScript Debug Terminal”
- Run test command in the debug terminal