gps-denied-desktop/docs/03_tests/16_database_layer_integration_spec.md

Integration Test: Database Layer

Summary

Validate the Database Layer for storing and retrieving flights, images, results, and system state.

Component Under Test

Component: GPS Denied Database Layer Location: gps_denied_17_gps_denied_database_layer Dependencies: PostgreSQL/SQLite database, SQL migrations

Detailed Description

Tests that Database Layer can:

1. Create database schema via migrations
2. Perform CRUD operations on all entities
3. Handle transactions atomically
4. Enforce foreign key constraints
5. Support concurrent access
6. Provide efficient queries with indexes
7. Handle connection pooling
8. Backup and restore data

Input Data

Test Case 1: Schema Creation

• Action: Run database migrations
• Expected: All tables created with correct schema

Test Case 2: Insert Flight

• Data: New flight record
• Expected: Flight inserted, ID returned

Test Case 3: Insert Images (Batch)

• Data: 10 image records
• Expected: All inserted in single transaction

Test Case 4: Insert Results

• Data: GPS result for processed image
• Expected: Result inserted with foreign key to image

Test Case 5: Query by Flight ID

• Query: Get all images for a flight
• Expected: Returns all images in correct order

Test Case 6: Update Result (Refinement)

• Action: Update existing result with refined GPS
• Expected: Result updated, version incremented

Test Case 7: Delete Flight (Cascade)

• Action: Delete flight
• Expected: Associated images and results also deleted

Test Case 8: Transaction Rollback

• Scenario: Insert flight, insert images, error occurs
• Expected: Transaction rolls back, no partial data

Test Case 9: Concurrent Writes

• Scenario: 5 simultaneous inserts to different flights
• Expected: All succeed, no deadlocks

Test Case 10: Query Performance

• Query: Complex join across flights, images, results
• Dataset: 1000 flights, 60,000 images
• Expected: Query completes < 100ms

Test Case 11: Index Effectiveness

• Query: Find image by ID
• Expected: Uses index, < 1ms lookup

Test Case 12: Connection Pooling

• Scenario: 100 rapid connections
• Expected: Pool reuses connections, no exhaustion

Expected Output

{
  "operation": "insert|select|update|delete",
  "success": true/false,
  "rows_affected": <integer>,
  "execution_time_ms": <float>,
  "error": "string|null"
}

Success Criteria

• All CRUD operations work correctly
• Transactions atomic (all-or-nothing)
• Foreign keys enforced
• Query performance acceptable
• Connection pooling works
• No SQL injection vulnerabilities

Maximum Expected Time

• Schema migration: < 5 seconds
• Single insert: < 10ms
• Batch insert (10): < 100ms
• Query: < 100ms
• Total test suite: < 60 seconds

Pass/Fail Criteria

Passes If: All operations succeed, performance acceptable, data integrity maintained Fails If: Data corruption, slow queries, deadlocks, constraint violations