Комментарии 1
А как вы предлагаете проверять что миграция работает? В примере выше сам код миграции выглядит очень опасным и хардкодным, так, что в самом нём ручную ошибку допустить легко. А то что он правильно мигрирует - никаких гарантий тем более нет. То что сохранено у вас в джейсонах не является тестируемыми данными, а только одним их частным случаем значений. Самый главный вопрос такого рода миграций, это не бизнесс логика мигрирования, а как раз свойство и ограничения данных, и их изменения в версиях. Примеры:
Раньше поле "Фамилия" было необязательно а стало обязательно.
Допустимые значения ресурсов изменились, тк вместе со структурой данных еще и конфигурация обновилась и стал выпадать новый ресурс из сундуков.
Раньше был филд - строка, а сейчас тот же филд и он же строка, но при этому код логики работает с этой строкой по другому.
Могу предложить хранить в коде сразу всю допустимость значений, и использовать эти данные (атрибуты, или генераторы вариантов) для генерации тест-кейсов, в которых все значимые варианты данных сгенерируются сразу. Это даст чуть болшее покрытие тестами, и от каких то банальных ручных ошибок мб избавит.
Миграции данных в Unity