SessionProxy: стратегия тестирования

Архитектурная схема (archify) →

Два слоя тестов с разными целями

make test-unit — быстрые тесты без Docker: шифрование/дешифрование (crypto), сопоставление правил blacklist, разрешение эффективной политики лимитов (policy resolver — та самая логика «самый строгий выигрывает»), аутентификация, асинхронный логгер. Эти тесты проверяют чистую логику в изоляции — им не нужна настоящая БД, потому что предмет проверки не про SQL, а про вычисления и сравнения в коде.

make test-integration — через testcontainers-go: поднимается настоящий Postgres и Redis, применяются реальные миграции. Эти тесты нужны именно там, где логика unit-тестов принципиально не может дотянуться: реальное поведение блокировок, реальные ограничения схемы (constraints, foreign keys), реальное взаимодействие компонентов через сеть, а не через вызов функции напрямую в памяти процесса.

Ключевой e2e-сценарий, который стоит уметь пересказать по шагам

1. Владелец импортирует сессию (куки/токены шифруются и сохраняются).
2. Владелец создаёт расшаренную ссылку с политикой лимитов.
3. Гость проходит по ссылке.
4. Целевой сайт (в тестовом окружении — сервис-заглушка echo-target, который просто показывает полученные заголовки) получает расшифрованную куку владельца.
5. Гость НЕ получает Set-Cookie в ответе — заголовок вырезан.
6. При превышении лимита или срабатывании blacklist ссылка переходит в статус terminated с верной причиной из revocation_reasons.
7. Строка лога долетает до proxy_access_logs, а дальше — по уже описанному CDC-пайплайну до ClickHouse.

Такой тест проверяет не отдельную функцию, а весь путь данных через систему целиком — именно это и есть содержательный ответ на вопрос «как вы тестировали, что прокси реально не палит куки», а не просто «у меня есть тесты».