# FR24 / RTL-SDR test plan

## 1. Цель
Проверить, что локальный RTL-SDR ingest-контур работает корректно, устойчиво восстанавливается после сбоев и отдаёт данные в noisemap / карту без потерь и без разъезда состояния.

## 2. Уровни тестирования

### 2.1 Smoke tests
Быстрая проверка, что стек вообще поднялся:
- Docker Compose стартует без ошибок
- `postgres` доступен внутри сети compose
- `capture` стартует и видит RTL-SDR
- `preprocess` стартует и подключается к БД
- `api` отвечает на health endpoint

### 2.2 Integration tests
Проверка связности компонентов:
- `capture` пишет записи в `raw_packets`
- `preprocess` читает `raw_packets` и обновляет `processing_state`
- `preprocess` создаёт/обновляет `flights`, `tracks`, `track_points`
- `api` читает данные из БД и отдаёт их в формате, нужном для карты
- PostGIS-функции работают на геометриях

### 2.3 Recovery tests
Проверка восстановления после сбоя:
- остановить `preprocess`
- продолжить запись сырья
- поднять `preprocess`
- убедиться, что он автоматически догоняет пропущенный диапазон
- проверить, что overlap не даёт дублей

### 2.4 Retention tests
Проверка хранения сырья:
- raw-данные доступны не менее 3 дней
- после истечения retention raw-слой чистится автоматически
- обработанные данные не удаляются вместе с raw без причины

### 2.5 Resource tests
Проверка в рамках лимитов VM:
- CPU не выходит за разумный потолок при live-режиме
- RAM не утекает при длительном прогоне
- диск не растёт неконтролируемо
- логирование и БД не съедают всё место

## 3. Минимальный smoke checklist
- [ ] VM загружается
- [ ] USB passthrough RTL-SDR работает
- [ ] `docker compose up -d` успешен
- [ ] `postgres` живой и PostGIS включён
- [ ] `capture` видит устройство
- [ ] `preprocess` пишет state
- [ ] `api` отвечает `/health`
- [ ] хотя бы одна тестовая запись проходит путь raw → core

## 4. Минимальный integration checklist
- [ ] raw packet попадает в `raw_packets`
- [ ] создаётся/обновляется `captures`
- [ ] создаётся/обновляется `aircraft`
- [ ] создаётся/обновляется `flights`
- [ ] создаются `track_points`
- [ ] обновляется `tracks`
- [ ] `processing_state` отражает последний checkpoint
- [ ] `api` возвращает данные для визуализации

## 5. Recovery сценарий
### Сценарий A: preprocess down
1. Остановить `preprocess`
2. Записать часть сырья
3. Запустить `preprocess`
4. Проверить, что недостающий диапазон дочитан
5. Проверить отсутствие дублей на overlap

### Сценарий B: temporary DB restart
1. Перезапустить `postgres`
2. Проверить, что контейнеры восстанавливают соединение
3. Проверить, что `capture` и `preprocess` не теряют состояние навсегда

### Сценарий C: capture restart
1. Перезапустить `capture`
2. Проверить, что new live поток продолжает попадать в raw слой
3. Проверить, что recovery не ломается после краткой паузы

## 6. Data correctness checks
- координаты в допустимых диапазонах
- время монотонно внутри одного трека/сессии там, где это ожидается
- `track_points` привязаны к правильному `flight`/`track`
- `tracks` и `flights` не расходятся по времени и объёму
- геометрии PostGIS валидны

## 7. Performance checks
- нет резкого роста latency на ingest
- процесс recovery не блокирует live ingest
- API отвечает в приемлемое время на типовые запросы карты
- индексы реально используются, а не декоративны

## 8. What must be proven before handoff to Слава
Перед передачей Славе должны быть подтверждены:
- compose stack поднимается и переживает restart
- USB RTL-SDR стабильно доступен в VM
- raw retention работает
- recovery работает
- карта может читать данные из API
- БД и схема не вываливаются за лимиты VM
- базовые smoke/integration tests пройдены

## 9. Что должен вернуть Dev-агент
В отчёте Dev-агента должны быть:
- список тестов, которые он запускал
- команды, которыми он тестировал
- результаты smoke/integration/recovery tests
- замечания по рискам
- список того, что требует реального RTL-SDR железа для final verification