# 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/)