86 lines
3 KiB
Markdown
86 lines
3 KiB
Markdown
|
# NXTGAUGE Backend Testing Strategy
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
This document outlines the testing strategy for the NXTGAUGE Rust backend to ensure comprehensive test coverage for platform validation.
|
||
|
|
|
||
|
|
## Test Categories
|
||
|
|
|
||
|
|
### 1. Unit Tests
|
||
|
|
- Test individual functions and methods in isolation
|
||
|
|
- Mock external dependencies (database, Redis, email, external services)
|
||
|
|
- Focus on business logic validation
|
||
|
|
- Located in `*/tests/` directories within each crate/app
|
||
|
|
|
||
|
|
### 2. Integration Tests
|
||
|
|
- Test API endpoints with real database connections
|
||
|
|
- Test service-to-service communication via gateway
|
||
|
|
- Test authentication flows
|
||
|
|
- Test database repository methods
|
||
|
|
- Located in `/tests/integration/`
|
||
|
|
|
||
|
|
### 3. Contract Tests
|
||
|
|
- Validate API endpoints match the API CONTRACT specification
|
||
|
|
- Ensure request/response schemas are correct
|
||
|
|
- Test error handling matches documented error codes
|
||
|
|
|
||
|
|
### 4. Platform Workflow Tests
|
||
|
|
- Test complete user journeys spanning multiple services
|
||
|
|
- Example: Registration → Role Selection → Onboarding → Verification → Dashboard Access
|
||
|
|
- These will primarily be in the frontend Playwright tests but backed by backend API tests
|
||
|
|
|
||
|
|
## Test Implementation Plan
|
||
|
|
|
||
|
|
### Phase 1: Database Test Fixtures
|
||
|
|
Create reusable test database setup/teardown helpers
|
||
|
|
|
||
|
|
### Phase 2: Authentication Integration Tests
|
||
|
|
Test complete auth flow:
|
||
|
|
- User registration
|
||
|
|
- Email verification
|
||
|
|
- Login/logout
|
||
|
|
- Token refresh
|
||
|
|
- Protected route access
|
||
|
|
- Role switching
|
||
|
|
|
||
|
|
### Phase 3: Core Service Integration Tests
|
||
|
|
Test key services:
|
||
|
|
- Users service (role management, permissions)
|
||
|
|
- Companies service (job posting, applications)
|
||
|
|
- Profession services (profile, lead requests, wallet)
|
||
|
|
- Customers service (requirements management)
|
||
|
|
- Employees service (HR management)
|
||
|
|
- Notification system
|
||
|
|
- Knowledge base
|
||
|
|
- Approval workflows
|
||
|
|
- Pricing/Tracecoin system
|
||
|
|
|
||
|
|
### Phase 4: Gateway and Routing Tests
|
||
|
|
Test that the gateway properly routes to all services
|
||
|
|
Test middleware (authentication, rate limiting, etc.)
|
||
|
|
|
||
|
|
### Phase 5: Contract Validation Tests
|
||
|
|
Automatically validate that API endpoints match the specification in API_CONTRACT.md
|
||
|
|
|
||
|
|
## Tools and Dependencies Already Added:
|
||
|
|
- tokio (with test features) - for async testing
|
||
|
|
- reqwest - for making HTTP requests to test servers
|
||
|
|
- tower - for testing Axum services
|
||
|
|
- fake - for generating test data
|
||
|
|
- mockall - for mocking dependencies
|
||
|
|
- wiremock - for mocking external HTTP services (like Razorpay via Beeceptor)
|
||
|
|
- tempfile - for temporary file handling in tests
|
||
|
|
|
||
|
|
## Environment Variables for Testing:
|
||
|
|
Tests should use:
|
||
|
|
- TEST_DATABASE_URL (separate test database)
|
||
|
|
- Test JWT secrets
|
||
|
|
- Mock SMTP settings
|
||
|
|
- Mock external service URLs
|
||
|
|
- Feature flags set appropriately for testing
|
||
|
|
|
||
|
|
## Implementation Approach:
|
||
|
|
1. Each service gets its own integration test module
|
||
|
|
2. Shared test helpers for database setup, authentication helpers, etc.
|
||
|
|
3. Tests run against actual PostgreSQL instance (using testcontainers or dedicated test DB)
|
||
|
|
4. External services mocked where appropriate (email, Redis, external APIs)
|
||
|
|
5. Focus on testing happy paths and key error conditions
|