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