Вот тут не скажу, никогда не приходилось. Если совсем никак, и знаний плюсов не хватает, то только готовые проверенные биндинги юзать, своё писать не рекомендую, т.к. чревато течкой памяти и прочими неприятностями.
Сам несколько раз использовал биндинги в проектах, и могу сказать, что не все так радужно. Как минимум, работает не очень-то быстро, т.к. данные постоянно копируются туда-сюда, происходит переключение рантайма. Компиляция, безусловно, медленнее (это было чуть ли не решающим фактором ухода от биндингов). Кросс-компиляции можно сказать "Пока!". Тулзы для валидации кода (линтеры и прочие плюшки) откажутся работать. Если падает сишный код, сложно сказать почему. Ну и, вполне возможно, что потянется зависимость от внешних сишных библиотек, т.е. прощаемся с единственным бинарником.
Думаю, можно продолжить список, но я для себя вывод сделал. Можно использовать иногда, например, как мы сделали тут: https://github.com/kib357/less-go
GIN отлично работает. Query в GET запросах совершенно правильно используется, это не костыль. POST применять для получения данных, как раз, идеологически не верно.
Более того, GIN даже не даст пересекающиеся маршруты создать.
Предполагаю, что корень проблемы в функции app.InfoPageHand. Её смотреть надо. Сам GIN никогда редирект делать не будет.
Могу сказать только, что нужно всеми силами стараться избегать сишных биндингов в го.
Ну и не забывать первым делом в офдоки смотреть: https://github.com/golang/go/wiki/cgo
В го примеров таких нет, к сожалению. Заглушки для БД можно и не делать большими, ведь ясно что они должны вернуть. Либо вообще тестировать с нормальной базой. В тесте прописать доступ к тестовому инстансу, например.
Шаблонизатор вообще незачем тестировать – это функционал сторонней библиотеки. Если она не работает, то нужно чинить её, а не ваш код.
Владимир Грабко: Не достаточно канал jobs закрыть.
Сюда wg.Wait() выполнение не придёт, пока не закроется results. range по каналам работать до тех пор, пока канал не закроют.