JSON fixtures без клиентских данных: повторяемый пример для теста
Готовим синтетический JSON через ограниченную mock-схему, фиксируем seed и версию, отделяем тестовые email и ошибки от реальных пользовательских записей.
Fixture — заранее подготовленные данные, на которых воспроизводится тест. Для проверки структуры API обычно не нужны реальные имена, адреса и заказы клиентов. Нужны типы, связи и пограничные значения, способные вызвать конкретное поведение.
Синтетический пример полезно создать отдельно от production-выгрузки. Замена одной фамилии в настоящем документе не делает остальные поля искусственными: там могут остаться email, токены, свободный текст и идентификаторы. Цель здесь практическая — воспроизвести программную ошибку без копирования клиентской записи.
Маленькая схема для генератора
В mock JSON генераторе Neraviko используется собственная ограниченная схема полей. Это не произвольный JSON Schema Draft 2020-12 и не валидатор бизнес-модели.
Синтетическая схема:
{
"fields": [
{"name":"id","type":"integer","min":1,"max":3},
{"name":"email","type":"email"},
{"name":"active","type":"boolean"}
]
}
Настройки: count=2, seed=nrvo-fixture-v1, pretty=false, trailing_newline=false. Локально воспроизведённый результат текущей операции версии 1:
[{"id":3,"email":"user334355@example.test","active":true},{"id":1,"email":"user392500@example.test","active":true}]
Ответ также содержит meta.synthetic=true и metadata генератора: версию, seed, count и алгоритм hmac_sha256. Email используют example.test; они не обещают существование почтового ящика. Домен .test зарезервирован для тестирования. RFC 2606.
Не отправляйте тестовые письма только потому, что строка похожа на email. В этом сценарии данные нужны для fixture, а не для проверки доставки. Флаг active тоже не означает существующую активную учётную запись.
Проверяем экспорт
Следующий Python-пример проверяет именно этот JSON без сети и внешних зависимостей:
import json
source = '[{"id":3,"email":"user334355@example.test","active":true},' \
'{"id":1,"email":"user392500@example.test","active":true}]'
records = json.loads(source)
assert len(records) == 2
for record in records:
assert set(record) == {"id", "email", "active"}
assert type(record["id"]) is int and 1 <= record["id"] <= 3
assert record["email"].endswith("@example.test")
assert type(record["active"]) is bool
print("fixture check passed")
Проверенный вывод — fixture check passed. Этот тест не считает email доставляемым и не проверяет настоящую учётную запись. Для структуры более сложного документа можно отдельно использовать JSON Schema validator с согласованными правилами.
Что сохранить для воспроизводимости
Сохраняйте экспортированный результат, схему генератора, seed, настройки и версию. Одинаковый seed без остальных параметров недостаточен: новая схема может потреблять последовательность значений иначе, а новая версия — изменить алгоритм.
В Neraviko при отсутствии seed создаётся случайный seed и возвращается в meta.generator.seed. Его можно повторно использовать с той же схемой и настройками. Для регрессии удобнее зафиксировать seed явно и хранить его как часть тестового описания. Он относится к тестовым данным, а не является паролем.
Полезно также записать ожидаемое поведение: например, успешный импорт двух строк или отказ при пустом обязательном поле. Файл без цели быстро превращается в набор произвольных данных. Одной fixture не нужно моделировать весь бизнес: маленький сценарий проще читать и поддерживать.
Случайный пример не гарантирует покрытие границ
Генератор может выдать два разных ID в нашем примере, но это не обещание уникальности всех целых во всех запусках. Если контракт требует уникальные ID, проверьте это условие отдельно или подготовьте фиксированную последовательность в тесте. Не увеличивайте count в надежде случайно получить нужную ошибку.
Для null, отсутствующего поля, пустой строки или конкретного нарушения схемы создайте явные учебные варианты из безопасного шаблона. Статус синтетических данных сохраните в описании каждого файла. Такие ошибки должны быть намеренными и иметь ожидаемый результат, а не выглядеть как случайная повреждённая выгрузка.
Ограничения генератора
Операция v1 поддерживает собственные field types: string, name, email, date, integer, number, boolean, array и object. count ограничен диапазоном 1–50, схема — четырьмя уровнями вложенности и другими пределами сложности. Числовые границы в генераторе ограничены −1 000 000…1 000 000; decimal output — до четырёх знаков после запятой.
Запрос операции ограничен 65 536 байтами и общими лимитами API. Обработка серверная: схема отправляется Neraviko. Для определения полей не нужны реальные примеры клиентов. Не добавляйте клиентские записи в поле string values только ради большей реалистичности.
Генератор не заявляет обезличивание произвольной выгрузки, сохранение статистики production или автоматическую проверку всех связей. Он создаёт тестовые значения по заданной схеме. Для команды полезен небольшой набор fixtures, каждая с ясной целью и проверкой; его можно прогонять при изменении импорта вместо повторного копирования рабочих данных.