Как сгенерировать много UUID сразу для тестовых данных

Список UUID для тестов нужен, когда фикстуры, мок-ответы API и строки в CSV должны отличаться друг от друга без ручного набора. Один код копируют из документации. Десять и пятьдесят — уже пакет: сгенерировали, вставили, прогнали сценарий. Зачем вообще нужен уникальный идентификатор и чем версии отличаются — в UUID: зачем генерировать. Здесь практика пакета: сколько штук за раз, как разложить по файлам, куда не класть «красивые» последовательные id и как проверить, что в наборе нет дублей по вашей ошибке вставки. Откройте генератор UUID на Тулси, задайте число и скопируйте список. Ниже: сценарии тестовых данных, форматы вставки, типичные сбои и соседние шаги перед коммитом фикстур.

Когда нужен именно список, а не один код

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

Параллельные прогоны ломаются на id = 1, id = 2: второй воркер натыкается на чужую запись. Случайные коды из пакета снимают эту зависимость, если вы не зашили один и тот же набор в общий файл без изоляции.

Мок API часто отдаёт массив объектов. Удобно заранее иметь колонку id из генератора и подставлять её в JSON. Тогда дифф теста стабилен по структуре и не спорит с автоинкрементом базы.

Фикстуры базы и seed-скрипты

В seed-скрипте заранее положите двадцать UUID в массив или в CSV. Скрипт читает список и вставляет строки. Не генерируйте «на лету» в цикле без фиксации, если позже сравниваете снимок базы с эталоном: эталон должен знать те же ключи.

Если эталон не нужен, генерация в тесте допустима. Тогда список с сайта удобен для ручного прогона и для наполнения .env.example демо-данными.

Моки, Postman и ручные стенды

В коллекции запросов вставьте готовые id в переменные окружения. Пакет с генератора UUID копируется целиком: меньше шансов дважды вставить один код из буфера.

На демонстрации заказчику «случайные» id выглядят правдоподобнее, чем user-1. Не путайте это с продакшен-секретами: тестовые UUID не пароли.

Как получить и вставить пакет на Тулси

Откройте генератор UUID. Укажите, сколько кодов нужно (в пределах лимита интерфейса). Нажмите создание списка. Скопируйте результат одной операцией.

Вставьте список в редактор. Разделители обычно перевод строки: каждая строка — один код. Для CSV добавьте заголовок колонки и при необходимости другие поля рядом.

Повторите генерацию, если нужен второй независимый набор: например, id заказов отдельно от id пользователей. Не дописывайте вручную «похожий» код — так появляются опечатки и коллизии в голове, не в алгоритме.

Форматы: строки, JSON, CSV

Строка с дефисами — привычный вид: 8-4-4-4-12. В JSON кладите значение в кавычки. В SQL иногда нужен тип UUID без лишних пробелов и кавычек по правилам вашей СУБД.

Перед коммитом уберите пустые строки и пробелы по краям. Один лишний пробел ломает сравнение в тесте «строгое равенство».

Сколько штук генерировать за раз

Для юнит-теста часто хватает трёх–пяти. Для интеграционного сценария с несколькими сущностями — десятки. Не создавайте тысячи вручную через браузер, если ваш фреймворк умеет выдавать UUID в коде: сайт — для быстрого пакета и демо, не для нагрузочного датасета.

Теория «зачем UUID вместо счётчика» — в UUID: зачем генерировать. Здесь достаточно помнить: в тестах вы покупаете независимость прогонов, а не «красоту строки».

Типичные ошибки при работе со списком

Самая частая — вставить один и тот же UUID в две сущности «главная» и «зависимая», думая, что так проще отладить связь. Связь задайте отдельным полем внешнего ключа, а первичные ключи оставьте разными.

Вторая ошибка — смешать верхний и нижний регистр hex в системах, где сравнение чувствительно к регистру. Держите один стиль, как выдаёт генератор.

Третья — закоммитить прод-данные рядом с тестовым списком. Тестовые коды можно в репозиторий. Живые идентификаторы клиентов — нет.

Дубли после «ручной правки»

Генератор пакета не обязан «помнить» прошлый раз. Если вы склеили два скопированных блока и не проверили пересечение, дубль возможен из-за вашей склейки. Прогоните уникальность сортировкой или скриптом перед сидом.

Внутри одного ответа инструмента коды рассчитаны как независимые случайные значения версии, которую выдаёт страница. Не сокращайте их вручную «для читаемости».

Когда лучше генерировать в коде теста

Если каждый прогон должен быть полностью чистым и ключи не сравниваются с золотым файлом — вызывайте библиотеку UUID в сетапе. Список с сайта тогда нужен только для ручных стендов и документации примеров.

Если золотой файл или демо-дамп фиксированы — пакет с генератора UUID удобно один раз положить в репозиторий и больше не трогать.

Чеклист перед коммитом фикстур

Проверьте: все id уникальны в файле; нет прод-ключей; формат одинаковый; внешние ключи ссылаются на существующие строки. Прогоните один тест локально.

Подпишите в README фикстур, откуда взяты коды и можно ли их менять. Коллега не должен «обновить парочку id» без понимания связей.

Если объясняете новичкам смысл UUID, дайте ссылку на UUID: зачем генерировать, а пакет пусть собирают здесь по инструкции выше.

Смежные темы

Смысл и версии идентификатора: UUID: зачем генерировать. Пакет на сайте: генератор UUID.

Соседние утилиты для тестовых данных и отладки смотрите в блоке инструментов разработчика на Тулси: пароли, кодировки, разбор JSON — по задаче стенда.

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

Чем статья отличается от «зачем нужен UUID»?

Там — зачем уникальный код в принципе и где его ставят. Здесь — как быстро получить много кодов для тестов и аккуратно вставить их в фикстуры. Начните с пакета на генераторе UUID, теорию доберите в UUID: зачем генерировать.

Сколько UUID можно получить за один раз на Тулси?

Смотрите лимит на странице генератора UUID: интерфейс задаёт верхнюю границу за один запрос. Для типичных фикстур этого хватает. Большие выборки лучше собирать в коде вашего фреймворка.

Где создаются коды — на сервере или у меня?

На устройстве в браузере, без необходимости слать список на сервер для самой генерации. Это удобно для локальных тестов. Всё равно не вставляйте в фикстуры секреты и персональные данные.

Можно ли использовать один список во всех тестах сразу?

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

Нужны ли дефисы в UUID для базы?

Обычно да: каноническая запись с дефисами. Некоторые системы принимают и сжатую форму из 32 hex-символов. Следуйте типу колонки и драйверу. Не смешивайте оба вида в одном файле фикстур.

Что делать, если тест падает на «duplicate key»?

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

UUID в тестах — это то же, что в продакшене?

Тот же формат семейства идентификаторов. Разница в процессе: в тестах вы контролируете набор заранее. В проде чаще выдаёт приложение или база при создании записи. Не копируйте тестовые ключи в боевые таблицы «для удобства».

Как вставить список в Excel или Google Таблицы?

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

Стоит ли сокращать UUID в тестах до восьми символов?

Для отладки в логах иногда показывают короткий префикс. В ключе сущности храните полный код. Обрезка повышает риск случайного совпадения в больших наборах и путает сравнение.

Где сгенерировать список прямо сейчас?

Откройте генератор UUID, укажите число, скопируйте результат. Зачем такие коды нужны в архитектуре — читайте UUID: зачем генерировать. После вставки прогоните один тест с новой фикстурой.

Соберите пакет на генераторе UUID и разложите по фикстурам без ручного дописывания «на глаз». Смысл идентификатора и выбор версии: UUID: зачем генерировать.