DmitriyTitov

В таких случаях нужно разделить сложносоставную функцию на части. Что я имею в виду? Предположим, что ваша функция запрашивает данные из сети или читает с диска и потом их обрабатывает. В этом случае написать надёжный автотест не получится. Ведь сеть и диск - это всегда неопределённость. Поэтому следует разделить функцию на две - получение данных и обработка данных. В этом случае обработку данных легко тетировать передав в тест специально подготовленные данные. А функцию получения данных уже можно тестировать либо на эмуляторе источника (БД в памяти, тестовый сервер, специальные файлы и т.д.) либо вообще на заглушке. А может даже и на реальных источниках данных - всё зависит. При этом формально у вас будут и юнит-тесты и интеграционные тесты при использовании в тестах внешних компонент.

Тест написан корректно. А вот основная программа, по всей видимости, нет. Приведите текст main.go.
Ну или смотрите в нём строчку №80, как пишет дамп стека выполнения.

Я не специалист по MySQL, но эта СУБД, как и почти все современные реляционные СУБД, поддерживает тип данных JSON. В случаях вроде вашего я "эмулирую" MongoDB в реляционной СУБД создавая таблицу с полем ID - автоинкремент и полем DATA - JSON. И уже в JSON добавьте поле версия и что угодно.
Этим вы также и решите проблему с новыми полями анкеты.
Можно добавить JSON и к существующей таблице, а можно написать утилиту миграции. Оба пути сравнительно простые.

Есть довольно популярное в отрасли мнение (я его же придерживаюсь), что в Go нет действительно нужных фреймворков. Возможно они что-то и упрощают, но в сложных проектах вы будете не один и, соответственно, учить фреймворк придётся всем. При этом мощных преимуществ у фреймворков (типа как в JS) в Go нет. Это касается любых фреймворков, не только веб.
При этом я не призываю отказываться от полезных разных внешних пакетов-зависимостей. Главное, чтобы они были узконаправленными и не меняли идиоматику языка.