integration test placeholders

tests/integration/health/README.md

@@ -0,0 +1,94 @@
+# 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/)