95 lines
3.5 KiB
Markdown
95 lines
3.5 KiB
Markdown
# Health Integration Tests
|
|
|
|
This directory contains integration tests for health-related functionality in the GridPilot project.
|
|
|
|
## Purpose
|
|
|
|
These tests verify the **orchestration logic** of health-related Use Cases and their interactions with Ports using **In-Memory adapters**. They focus on business logic, not UI rendering.
|
|
|
|
## Test Structure
|
|
|
|
### 1. API Connection Monitor Tests (`api-connection-monitor.integration.test.ts`)
|
|
|
|
Tests the `ApiConnectionMonitor` class which handles:
|
|
- **Health check execution**: Performing HTTP health checks against API endpoints
|
|
- **Connection status tracking**: Managing connection states (connected, degraded, disconnected, checking)
|
|
- **Metrics calculation**: Tracking success/failure rates, response times, and reliability
|
|
- **Event emission**: Emitting events for status changes and health check results
|
|
|
|
**Key Scenarios:**
|
|
- Successful health checks with varying response times
|
|
- Failed health checks (network errors, timeouts)
|
|
- Connection status transitions (disconnected → connected, connected → degraded)
|
|
- Reliability and average response time calculations
|
|
- Multiple endpoint fallback strategies
|
|
- Event emission patterns
|
|
|
|
### 2. Health Check Use Cases Tests (`health-check-use-cases.integration.test.ts`)
|
|
|
|
Tests the health-related Use Cases:
|
|
- **CheckApiHealthUseCase**: Executes health checks and returns status
|
|
- **GetConnectionStatusUseCase**: Retrieves current connection status and metrics
|
|
|
|
**Key Scenarios:**
|
|
- Successful health check execution
|
|
- Failed health check handling
|
|
- Connection status retrieval (connected, degraded, disconnected, checking)
|
|
- Metrics calculation and formatting
|
|
- Event emission for status changes
|
|
- Error handling and validation
|
|
|
|
## Testing Philosophy
|
|
|
|
These tests follow the **Clean Integration Strategy**:
|
|
|
|
1. **Focus on Use Case Orchestration**: Tests verify how Use Cases interact with their Ports (Repositories, Adapters, Event Publishers)
|
|
2. **In-Memory Adapters**: Use in-memory implementations for speed and determinism
|
|
3. **Business Logic Only**: Tests verify business logic, not UI rendering or external dependencies
|
|
4. **Given/When/Then Structure**: Clear test scenarios with explicit preconditions and expected outcomes
|
|
|
|
## Test Categories
|
|
|
|
### Success Path Tests
|
|
- Verify correct behavior when all operations succeed
|
|
- Test with various data scenarios (minimal data, complete data, edge cases)
|
|
|
|
### Failure Path Tests
|
|
- Verify error handling for network failures
|
|
- Test timeout scenarios
|
|
- Handle malformed responses
|
|
|
|
### Edge Case Tests
|
|
- Empty or missing data
|
|
- Concurrent operations
|
|
- Invalid inputs
|
|
|
|
### Metrics Calculation Tests
|
|
- Reliability percentage calculation
|
|
- Average response time calculation
|
|
- Status transition logic
|
|
|
|
## Running Tests
|
|
|
|
```bash
|
|
# Run all health integration tests
|
|
npm test -- tests/integration/health/
|
|
|
|
# Run specific test file
|
|
npm test -- tests/integration/health/api-connection-monitor.integration.test.ts
|
|
```
|
|
|
|
## Implementation Notes
|
|
|
|
These are **placeholder tests** with TODO comments. They define the test structure and scenarios but do not contain actual implementation. When implementing:
|
|
|
|
1. Create the necessary In-Memory adapters in `adapters/health/persistence/inmemory/`
|
|
2. Create the Use Cases in `core/health/use-cases/`
|
|
3. Create the Ports in `core/health/ports/`
|
|
4. Implement the test logic following the Given/When/Then patterns defined in each test
|
|
|
|
## Related Documentation
|
|
|
|
- [Clean Integration Strategy](../../../plans/clean_integration_strategy.md)
|
|
- [Integration Test Pattern](../README.md)
|
|
- [BDD E2E Tests](../../e2e/bdd/health/)
|