Воспроизводимые UUID для тестовых фикстур: как использовать seed

В тестах полезно получать один и тот же набор идентификаторов: снимок ответа не меняется при каждом запуске, связи между искусственными записями остаются стабильными, ошибку проще воспроизвести. Для этой задачи генератор UUID Neraviko поддерживает seed.

Этот режим нужен для фикстур, примеров и воспроизводимых проверок. Повторяемый набор нельзя использовать как источник новых рабочих идентификаторов: повторная генерация намеренно даёт уже существующие значения.

Зафиксируйте параметры теста

В генераторе UUID задайте:

• count=2;
• seed=guide-fixture-v1;
• uppercase=false.

Seed — строка от 1 до 128 байт. Для переносимого примера используйте простой ASCII-текст. Лимит в байтах важен для кириллицы и emoji: число символов не обязательно совпадает с числом байтов.

Синтетический запрос операции data.generate_uuid:

{"input":null,"options":{"count":2,"seed":"guide-fixture-v1","uppercase":false}}

Проверенный локально результат версии 1:

07f7f6ad-b06e-4aaa-8e69-15c2c6d1508c
e524b401-0564-4a14-a2c7-5d7c2109b08c

Повтор с теми же параметрами возвращает те же строки в том же порядке. Это полезный ожидаемый результат для теста: сравнивать нужно весь упорядоченный массив, а не только соответствие формату.

Почему результат повторяется

В текущей реализации байты получаются через HMAC-SHA256. Контекст включает операцию data.generate_uuid:v1 и индекс элемента. Затем генератор выставляет биты версии и варианта. В метаданных будет algorithm=hmac_sha256, версия 1 и заданный seed.

Полученные строки имеют формат v4. Описание формата версии и варианта приведено в RFC 9562, раздел 5.4, май 2024; проверено 05.10.2026. Воспроизводимость данного режима — контракт реализации Neraviko, а не обещание стандарта, что любой UUID-генератор с таким seed выдаст эти строки.

Не пытайтесь воспроизвести пример в другой библиотеке простым вызовом «UUID v4 с seed»: алгоритм, контекст и порядок выборки байтов могут отличаться. Для устойчивых тестов сохраняйте версию инструмента, параметры и ожидаемый массив рядом с фикстурой.

Как организовать тестовый набор

Выберите осмысленное имя seed, например orders-import-fixture-v1. Сохраните рядом описание, какие сущности соответствуют позициям массива. Первая строка может принадлежать заказу, вторая — строке заказа; именно эта связь, а не случайность значения, делает набор полезным.

При изменении структуры теста либо сохраните прежние назначения индексов, либо заведите новый seed и обновите ожидаемые результаты осознанно. Перестановка UUID в фикстуре может сохранить корректный формат и всё равно сломать связи.

Больший count не означает отдельное продолжение последовательности: каждый новый запрос начинает индексы заново. Если выполнить два запроса с одинаковым seed и count=2, получится два одинаковых набора, а не четыре новых значения. Для отдельного сценария используйте другой seed и проверьте ожидаемый результат.

uppercase=true даёт другой текстовый регистр тех же значений. Если сравниваете снимки как строки, регистр нужно тоже зафиксировать. Это особенно важно, когда один участок тестовой инфраструктуры нормализует UUID, а другой хранит текст буквально.

Выберите назначение фикстуры до генерации

Начните с минимального сценария: например, две искусственные сущности и одна связь между ними. Выпишите, какие идентификаторы должны совпадать между таблицами, а какие обязаны различаться. Затем присвойте каждой позиции массива конкретную роль и сохраните это соответствие рядом с данными. Сам список UUID не объясняет тесту структуру связей.

Для нескольких независимых сценариев используйте отдельные описательные seed. Тогда изменение набора одной проверки не требует переписывать все остальные. Название seed не должно содержать настоящие персональные данные или рабочие секреты: для повторяемости достаточно искусственного имени сценария.

При загрузке фикстуры проверьте, что она попала именно в тестовую среду и что повторное выполнение не оставляет лишние записи от прежнего набора. Правило очистки или переиспользования должно учитывать зависимые сущности, иначе прежние связи могут сделать тест случайно успешным. Приёмка готовой фикстуры включает корректные связи и повторную загрузку, а не только одинаковую печать двух строк.

Контроль перед фиксацией

1. Все сущности искусственные; реальные пользовательские данные не нужны.
2. Seed, версия операции и опции сохранены в описании теста.
3. Два независимых вызова дают одинаковый упорядоченный массив.
4. У каждого индекса есть согласованное назначение.
5. Повторная загрузка фикстуры очищает или переиспользует тестовые записи по явному правилу.
6. Этот seed отсутствует в рабочем создании новых сущностей.

Веб-инструмент обрабатывает запрос на сервере. По контракту операции сырые параметры и сгенерированные результаты не сохраняются и не логируются по умолчанию. Для секретов выбирайте другой механизм: генераторы паролей и API-ключей Neraviko не принимают seed. Повторяемость, полезная тестовым идентификаторам, не должна становиться свойством рабочих секретов.