чисто технически вам в этом коде нужно коллега убедится в том, что данные из одного канала поступят в другой. Для этого вы можете пойти несколькими путями.

1. Путь неправильный коллега, создать топики для тестов в рэббите и убедится в коде теста, что туда все что вам нужно проваливается.
2. Создать абстракцию над чтением и записью в (интерфейсы Publisher, Subscriber), и воспользовавшись библиотекой для мокирования (gomock, testify) убедится, что нужные вызовы будут вызваны с ожидаемыми аргументами.

Традиционно разработчики считают, что код очевиндый и все работает как надо. Проблема может быть в том, что кто-нибудь изменит конструктор и ваш реплиТу превритится во что-то иное, или вместо контент тайпа передасться другое. При определенной привычке этот код тестируется за количество времени 0.6 от его набивания на клавиатуре.

Лично мое мнение, любой код должен быть протестирован. Удивительно сколько опечаток, микроошибочек и прочих проблем находит юнит-тест. Но это больше говорит о том, что я невнимательный и больной на голову старикан.

По поводу непосредственно этой библиотеки, учтите, что она не умеет восстанавливать соединение с брокером и при любом моргании сети - вы получите остановившийся сервис.

Так что или напишите код для реконнекта или возьмите, что-то более похожее на "клиентское решение".

Поддержу @murmurchik, такое бывает редко, а еще в коде мне видятся проблемы, в newserver не закроется конекшен и ченел если после их открытия в этой функции будет error, в handleDelivered вообще ошибки не обработаны, метода Close  тоже нет. Скажу сразу про amqp клиент мало помню.

необработка ошибок в клиенте будет приводить к разным моментам. К тому же тут судя по всему autoack, так что если у вас внезапно не удасться записать в брокер запись, то из очереди она уже исчезнет.

Ack делается явно

действительно. но тут он фактически "авто".

Ваша правда

кроме контент-тайпа не ожидаемого. надеюсь есть какой-то еще процесс который будет эти ошибочные записи удалять из очереди.

тут очевидно уже много сценариев которые стоило бы проверить.

Но ведь роб пайк обещал что все будет просто и больно только в первый раз, как так то?

запятую, перед "что", забыли.

т.е., иными словами, за удаление из очереди ошибочных записей, должен отвечать сервер, обслуживающий эту очередь?

Я уже сообщал вам о своем колхозном бекграунде, извините

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

https://github.com/golang/go/blob/master/test/if.go

Вот пример теста от самого Роба, он не постеснялся протестировать if, считаю так и нужно

@murmurchik спасибо за пищу для размышлений, слова Ваши услышал

ну вообще коллега, вот прямо такого рода код частенько можно увидеть в продакшене, без каких либо тестов.