Каждый спринт мы экспортируем JSON из Kibana, листаем сотни записей и говорим себе, что потом превратим их в тест-кейсы.

Потом никогда не наступает.

Логи содержат реальные API-вызовы. Настоящие endpoint’ы, реальные payload’ы, настоящие статус-коды из продакшна. Это ближайшее к спецификации описание того, как система ведёт себя на самом деле. И почти ничего из этого не становится автотестом. Потому что переводить вручную дольше, чем идёт спринт.

Я устал от «потом». Я написал secure-log2test, CLI-инструмент, который читает экспорт Kibana и генерирует готовый pytest-файл. Одна команда. Работающие тесты.

Главное ограничение, которое определило весь дизайн: никакие данные не покидают машину. Никаких вызовов LLM API. Никакого облака. Всё локально.

Почему privacy-ограничение важно

Очевидная альтернатива построению инструмента: попросить языковую модель написать тесты по логам. Скорее всего сработает. Ровно до момента, когда кто-то из безопасности заметит, что продакшн-логи с PII и внутренней структурой API уходят на внешний сервис.

В enterprise-среде этот разговор заканчивается плохо. Поэтому я сделал невозможным: в ядре нет сетевых вызовов.

Но большая часть privacy-истории не про сетевые вызовы, а про секреты внутри самих записей. Продакшн-логи всё время утекают с Authorization: Bearer ... headers. С Cookie, с X-API-Key. И всё чаще с request body, который содержит password, refresh_token, client_secret или как там команда назвала свой auth-field на этой неделе. Если сгенерированные тесты тащат эти значения, регрессионный набор превращается в дамп креденшелов на диске, готовый к случайному коммиту.

secure-log2test чистит три слоя до того, как тест-файл будет записан:

1. Статический список известных auth-заголовков (authorization, proxy-authorization, proxy-authenticate, cookie, set-cookie, x-api-key, x-auth-token, x-csrf-token, x-access-token, refresh-token, id-token, x-amz-security-token, authentication).

2. Regex pattern (auth|token|secret|key|session|cookie|credential|bearer|password|passwd), который ловит кастомные имена заголовков, которые команды придумывают сами.

3. Та же логика рекурсивно проходит JSON request body. Так что значения вроде {"password": "..."}, {"client_secret": "..."}, OAuth {"refresh_token": "..."} заменяются на ***REDACTED*** на этапе парсинга.

Маркер это плейсхолдер. Реальные креденшелы инжектятся в рантайме через переменные окружения или fixtures.

Как это работает

pip install secure-log2test

secure-log2test data/sample_kibana_export.json --output tests_generated.py
pytest tests_generated.py -v

В репо лежит sample-экспорт, можно увидеть реальный output без поднятия Kibana.

На входе стандартный Kibana JSON hits.hits[*]._source (формат любого saved search). На выходе pytest-файл с одной функцией на запись лога:

def test_post_api_v1_orders_1():
    response = requests.request(
        method="POST",
        url=BASE_URL + "/api/v1/orders",
        headers={"Authorization": "***REDACTED***", "Content-Type": "application/json"},
        json={"item_id": 42, "password": "***REDACTED***"},
        timeout=10,
    )
    assert response.status_code == 201

И header Authorization, и поле password внутри body заскраблены. Исходный dict не мутируется.

Архитектура: две стадии

Парсинг (core/parser.py). Pydantic v2 валидирует и нормализует записи. Записи с missing fields получают безопасные дефолты вместо краша. Невалидные записи дропаются с предупреждением, а не молча. Редакция запускается как Pydantic field_validator, так что её нельзя пропустить случайно.

Генерация (core/generator.py). Валидированный список идёт через Jinja2-шаблон (templates/test_module.py.j2) и приземляется как .py файл. Шаблон это единственное место, которое знает, как выглядит pytest. Хотите другой формат (httpx вместо requests, unittest вместо pytest, k6 scenarios)? Меняете шаблон, парсер не трогаете.

Цикл обратной связи, который дал v1.0.1

Первый PyPI релиз вышел как v1.0.0 11 мая. В течение часов внешний пользователь скормил инструменту Grafana Loki экспорт с кириллицей из российского бэкенда. Парсер открывал файл без явного encoding аргумента. На Linux всё работает (utf-8 by default). На Windows тот же вызов крашится с UnicodeDecodeError, потому что Windows дефолтит к cp1252.

Баг зарепортили, я воспроизвёл, исправил за день. v1.0.1 ушёл 13-го с явным encoding="utf-8-sig" на file open. Я добавил регрессионный тест, который симулирует cp1252-окружение, чтобы тот же баг не вернулся.

Чему научился: каждый фреймворк, который обрабатывает user-provided input, нуждается в adversarial encoding-тесте. Happy path тривиальный. Баг живёт в зазоре между «что делает моя dev-машина по дефолту» и «что делает Windows-shell по дефолту».

Что покрывают тесты

59 тестов на момент v1.1.0, по парсеру и генератору:

• Валидный вход, malformed-записи, missing fields, пустые экспорты.

• Header-редакция по статическому списку. Header-редакция по regex pattern. Кастомные заголовки команды вроде X-Custom-Token, пойманные паттерном.

• Body-редакция walker: password-поля, OAuth refresh tokens, вложенные dicts, списки dicts, non-dict pass-through.

• Float duration coercion (Kibana иногда выдаёт 134.0 вместо 134).

• Рендеринг шаблона, сериализация payload, naming тестов.

• CLI-аргументы, создание output path.

• CI smoke-тест, который гоняет CLI end-to-end на sample-экспорте и парсит сгенерированный Python через ast.parse.

CI бегает на Python 3.10, 3.11, 3.12 и 3.13 через GitHub Actions.

Честные ограничения

• Только Kibana / Elasticsearch JSON export shape. Grafana Loki Explore трекается в issue #4.

• Single-file вход. Multi-file batch-режим в roadmap.

• Output: только pytest. JSON / CSV для downstream pipelines трекается в issue #5.

• Грузит весь файл в память. Не для многогигабайтных экспортов.

• Не строит последовательности запросов и не определяет зависимости.

• Не заменяет ручное проектирование тестов. Ускоряет первый проход.

Сгенерированные тесты это стартовая точка. Вы их ревьюите, выставляете base URL через env, добавляете setup/teardown где нужно. Но начинаете с работающего кода, а не с чистого файла и стопки логов.

Куда движется

v1.1 добавит response body assertions и optional schema match (issue #1). v1.2 даст кастомные редакционные правила через config file (issue #2). Два good first issue слота открыты прямо сейчас, если хотите взять.

Попробовать

pip install secure-log2test

Репо (MIT): github.com/golikovichev/secure-log2test

Если ваш Kibana экспорт отличается от ожидаемого, откройте issue с redacted sample. Парсер это самая лёгкая часть для расширения.