https://pastein.ru/t/IkM
Загрузка данных
ак добавить новый dataset (покрытие "в ширину")
Когда это имеет смысл:
- есть новый набор данных и его нужно покрыть автотестами
- в TestOps (или в доступном хранилище) есть тест кейс и в нем архив данных имитатора .tar.gz
Как добавить:
1) Скопировать похожий конфиг:
- 1 утечка → взять test_config/datasets/select_6.py
- 2 утечки → взять test_config/datasets/select_19_20.py
2) Переименовать файл на select_XX.py
3) Внутри файла:
- обновить SUITE_NAME, SUITE_DATA_ID, ARCHIVE_NAME
- заполнить параметры утечки/утечек (координата/объём/интервалы)
- заполнить CaseMarkers для нужных тестов:
- test_case_id (из TestOps)
- offset (минуты от старта набора)
4) Готово: configs подхватятся автоматически при импорте test_config.datasets.ALL_CONFIGS.
### Важные правила
offset задаётся и используется для:
- ожидания перед тестом
- расчёта длительности имитатора для набора (max offset + задержка)
- Для multi‑leak:
- используйте leaks=[LeakTestConfig(...), LeakTestConfig(...)]
- id параметра будет <suite_name>_leak_N
Инструкция для разработчиков
Разработчик автотестов:
- понимает архитектуру setup/autotests/teardown
- может добавить новый dataset (покрытие "в ширину")
- может добавить новую проверку/сценарий (покрытие "в глубину")
- может разобраться, почему тест упал (диагностика по логам/TestOps)
Краткое описание архитектуры
- Один тестовый модуль: tests/test_smoke.py (suite‑level + leak‑level тесты).
- Параметризация идёт от test_config/datasets.ALL_CONFIGS (автопоиск конфигов).
- conftest.py:
а) добавляет --suites фильтр
б) навешивает offset/test_case_id маркеры из datasets
в) группирует тесты по test_suite_name
г) перезапускает стенд/имитатор при смене suite
д) в конце выгружает Allure в TestOps
- Сценарии тестов: test_scenarios/ (WS вызовы + ассерты по полям).
- WS клиент: clients/websocket_client.py (SignalR + messagepack - имитация фронта).
- Setup стенда: infra/stand_setup_manager.py (контейнеры/redis/clickhouse/имитатор/данные).
Жизненный цикл прогона: setup → autotests → teardown
Коллекция тестов (pytest collection)
Источник параметров:
- test_config/datasets/__init__.py сканирует test_config/datasets/*.py
- ищет атрибуты с суффиксом _CONFIG
- добавляет найденные SuiteConfig в ALL_CONFIGS
В tests/test_smoke.py из ALL_CONFIGS генерируются:
- SUITE_PARAMS: один параметр на набор
- LEAK_PARAMS: один параметр на утечку (для multi‑leak - несколько)
Фильтрация по --suites и отключённые тесты
В conftest.py реализовано:
- --suites=select_4,select_19_20 - фильтр по подстроке имени suite (test_suite_name)
- отсеивание тестов, где конфиг теста = None (то есть тест отключён для набора)
Группировка по suite и расчёт длительности имитатора
Ключевые идеи:
- каждый item имеет маркеры:
test_suite_name
test_suite_data_id
test_data_name
offset маркер навешивается автоматически из CaseMarkers.offset
- длительность работы имитатора считается как:
max(offsets в suite) + IMITATOR_FINISH_DELAY_MINUTE
Setup/teardown выполняются при смене набора данных
В conftest.py в pytest_runtest_setup, если текущий test_suite_name отличается от предыдущего:
- останавливаем старый имитатор (если был)
- поднимаем стенд под новый набор:
- останов сервисов (LB, journals, web-app, api-gw, reports)
- чистка Redis ключей
- чистка Clickhouse ключей
- старт сервисов (LB, journals, web-app, api-gw, reports)
- проверяем доступность OPC
- стартуем имитатор и core
- сохраняем imitator_start_time в group_state
В pytest_runtest_teardown:
- если следующий тест уже другого suite - останавливаем имитатор/чистим данные.
Инфраструктурная внутрянка
Этот раздел про то, как именно автотесты управляют стендом: где берутся данные, как выполняются команды на удалённом сервере, что стартует/стопается и в каком порядке.
Компоненты (кто за что отвечает)
infra/stand_setup_manager.py::StandSetupManager: оркестратор setup/teardown для одного suite.
- выбирает сервер стенда по STAND_NAME (через HOST_MAP)
- копирует файл конфигурации с выбранного стенда (требуется для чистки Clickhouse)
- создаёт клиентов для стенда, Redis и Clickhouse
- скачивает/загружает данные набора на стенд через TestOps
- поднимает сервисы и запускает имитатор + core
- отдаёт start_time имитатора (datetime) в conftest.py
infra/imitator_data_uploader.py::ImitatorDataUploader: доставка данных прогона на стенд.
- скачивает архив данных из TestOps по suite_data_id
- проверяет архив локально (runner)
- копирует архив на удалённый сервер (scp)
- распаковывает во временную директорию и валидирует структуру
infra/cmd_generator.py::ImitatorCmdGenerator + TimeProcessor: генерация команды запуска имитатора и расчёт startTime/stopTime.
infra/imitator_manager.py::ImitatorManager: запуск/логирование/останов имитатора как "длинного процесса".
infra/docker_manager.py::DockerContainerManager: stop/start групп контейнеров и проверка статусов.
infra/redis_manager.py::RedisCleaner: чистка ключей Redis для стенда.
infra/clickhouse_manager.py::ClickHouseManager: чистка ключей Clickhouse для стенда
clients/subprocess_client.py::SubprocessClient: транспорт для выполнения команд:
- run_cmd() → разовые команды (ssh wrapper)
- exec_popen() → длинные процессы (например запуск имитатора)
- умеет работать на Windows (добавляет ssh -i <SSH_KEY_NAME> ...), это требуется для запуска автотестов локально
clients/http_client.py::HttpClient: HTTP запросы в TestOps (attachments list/download).
Что именно приходит из datasets в инфраструктуру
SuiteConfig содержит два ключевых поля, которые инфраструктура использует напрямую:
- suite_data_id: id тест‑кейса в TestOps, откуда берём attachments (архив данных)
- archive_name: имя файла вложения (.tar.gz) внутри TestOps, которое нужно скачать
В tests/test_smoke.py они попадают в pytest маркеры:
- test_suite_data_id(suite_data_id)
- test_data_name(archive_name)
А в conftest.py при смене suite эти значения читаются и передаются в StandSetupManager(duration_m, test_data_id, test_data_name).
