gps-denied-onboard/docs/03_tests/11a_flight_lifecycle_manager_integration_spec.md

Integration Test: Flight Lifecycle Manager (F02.1)

Summary

Validate the Flight Lifecycle Manager component responsible for flight CRUD operations, system initialization, and API request routing.

Component Under Test

Component: Flight Lifecycle Manager (F02.1) Interface: IFlightLifecycleManager Dependencies:

• F03 Flight Database (persistence)
• F04 Satellite Data Manager (prefetching)
• F05 Image Input Pipeline (image queuing)
• F13 Coordinate Transformer (ENU origin)
• F15 SSE Event Streamer (stream creation)
• F16 Model Manager (model loading)
• F17 Configuration Manager (config loading)
• F02.2 Flight Processing Engine (managed child)

Detailed Description

This test validates that the Flight Lifecycle Manager can:

1. Create and initialize new flight sessions
2. Manage flight lifecycle (created → active → completed)
3. Validate waypoints and geofences
4. Queue images for processing (delegates to F05, triggers F02.2)
5. Handle user fix requests (delegates to F02.2)
6. Create SSE client streams (delegates to F15)
7. Initialize system components on startup
8. Manage F02.2 Processing Engine instances per flight

The Lifecycle Manager is the external-facing component handling API requests and delegating to internal processing.

Input Data

Test Case 1: Create New Flight

• Input:
  • Flight name: "Test_Baseline_Flight"
  • Start GPS: 48.275292, 37.385220
  • Altitude: 400m
  • Camera params: focal_length=25mm, sensor_width=23.5mm, resolution=6252x4168
• Expected:
  • Flight created with unique ID
  • F13.set_enu_origin() called with start_gps
  • F04.prefetch_route_corridor() triggered
  • Flight persisted to F03

Test Case 2: Get Flight

• Input: Existing flight_id
• Expected: Flight data returned with current state

Test Case 3: Get Flight State

• Input: Existing flight_id
• Expected: FlightState returned (processing status, current frame, etc.)

Test Case 4: Delete Flight

• Input: Existing flight_id
• Expected:
  • Flight marked deleted in F03
  • Associated F02.2 engine stopped
  • Resources cleaned up

Test Case 5: Update Flight Status

• Input: flight_id, status update (e.g., pause, resume)
• Expected: Status updated, F02.2 notified if needed

Test Case 6: Update Single Waypoint

• Input: flight_id, waypoint_id, new Waypoint data
• Expected: Waypoint updated in F03

Test Case 7: Batch Update Waypoints

• Input: flight_id, List of updated Waypoints
• Expected: All waypoints updated atomically

Test Case 8: Validate Waypoint

• Input: Waypoint with GPS coordinates
• Expected: ValidationResult with valid/invalid and reason

Test Case 9: Validate Geofence

• Input: Geofence polygon
• Expected: ValidationResult (valid polygon, within limits)

Test Case 10: Queue Images (Delegation)

• Input: flight_id, ImageBatch (10 images)
• Expected:
  • F05.queue_batch() called
  • F02.2 engine started/triggered
  • BatchQueueResult returned

Test Case 11: Handle User Fix (Delegation)

• Input: flight_id, UserFixRequest (frame_id, GPS anchor)
• Expected:
  • Active F02.2 engine retrieved
  • engine.apply_user_fix() called
  • UserFixResult returned

Test Case 12: Create Client Stream (Delegation)

• Input: flight_id, client_id
• Expected:
  • F15.create_stream() called
  • StreamConnection returned

Test Case 13: Convert Object to GPS (Delegation)

• Input: flight_id, frame_id, pixel coordinates
• Expected:
  • F13.image_object_to_gps() called
  • GPSPoint returned

Test Case 14: System Initialization

• Input: Call initialize_system()
• Expected:
  • F17.load_config() called
  • F16.load_model() called for all models
  • F03 database initialized
  • F04 cache initialized
  • F08 index loaded
  • Returns True on success

Test Case 15: Get Flight Metadata

• Input: flight_id
• Expected: FlightMetadata (camera params, altitude, waypoint count, etc.)

Test Case 16: Validate Flight Continuity

• Input: List of Waypoints
• Expected: ValidationResult (continuous path, no gaps > threshold)

Expected Output

For each test case:

{
  "flight_id": "unique_flight_identifier",
  "flight_name": "string",
  "state": "created|active|completed|paused|deleted",
  "created_at": "timestamp",
  "updated_at": "timestamp",
  "enu_origin": {
    "latitude": <float>,
    "longitude": <float>
  },
  "waypoint_count": <integer>,
  "has_active_engine": <boolean>
}

Success Criteria

Test Cases 1-5 (Flight CRUD):

• Flight created/retrieved/updated/deleted correctly
• State transitions valid
• Database persistence verified

Test Cases 6-9 (Validation):

• Waypoint/geofence validation correct
• Invalid inputs rejected with reason
• Edge cases handled

Test Cases 10-13 (Delegation):

• Correct components called
• Parameters passed correctly
• Results returned correctly

Test Case 14 (Initialization):

• All components initialized in correct order
• Failures handled gracefully
• Startup time < 30 seconds

Test Cases 15-16 (Metadata/Continuity):

• Metadata accurate
• Continuity validation correct

Maximum Expected Time

• Create flight: < 500ms (excluding prefetch)
• Get/Update flight: < 100ms
• Delete flight: < 500ms
• Queue images: < 2 seconds (10 images)
• User fix delegation: < 100ms
• System initialization: < 30 seconds
• Total test suite: < 120 seconds

Pass/Fail Criteria

Overall Test Passes If:

• All 16 test cases pass
• CRUD operations work correctly
• Delegation to child components works
• System initialization completes
• No resource leaks

Test Fails If:

• Flight CRUD fails
• Delegation fails to reach correct component
• System initialization fails
• Invalid state transitions allowed
• Resource cleanup fails on delete