Monkey patching? В Go? Серьёзно? Или как писать тесты и не сойти сума

[@MountainGoat]

С одной стороны да, а с другой – ну все же видели шутки про enterprise-friendly Hello world на пятьдесят классов. Когда time.now приходится выносить в отдельный класс-генератор, с отдельно описанным интерфейсом, и ещё с моком (уже 3 сущности) только ради теста – начинается плак-плак. Даже если ИИ заставить это всё писать.

[@Roman_Cherkasov]

А теперь попробуйте написать тест, который проверяет, что ID пользователя равен конкретному значению. Или что CreatedAt равен конкретному времени

Я может уже сонный конечно или глуповат... Но для чего? Какой кейс это покрывает? Есть сомнения что uuid.New() сгенерирует UUID? или что time.Now()вернет текущее время?

[@cs0ip]

Это просто пример. Автор в конце пишет про более реалистичные кейсы, когда UUID должен следовать определенным правилам. В дополнение можно привести кейс, когда UUID должен быть сортируемый по времени создания

[@Roman_Cherkasov]

Я ждал комментарий про "просто пример". Это не просто пример, это плохой пример.
Проблема таких примеров в том что люди их запоминают. А потом делают вот то что автор делает у себя в статье. Но если автор понимает для чего он это делает (предположим ему действительно надо "генерирует уникальные коды с префиксом на основе времени и счётчика") то люди занесут это без понимания, к себе в проекты. Потому что "в статье на хабре видел".

У статьи тег "туториал". И ни где не написано о том что делать так конечно не надо, это только для примера.

P.S. Если кто-то скажет, что это оверинжиниринг для простого uuid.New() — попросите их протестировать код, который генерирует уникальные коды с префиксом на основе времени и счётчика. А потом посмотрите, как они будут страдать с time.Sleep() в тестах :)

Этот кусок был дописан после того как я оставил комментарий, вместо того чтобы ответить на комментарий). Но все равно отвечу, что префикс можно и скорее всего нужно хранить в отдельном поле и тестировать правильность его создания, без учета UUID. Плохие архитектурные решения - не повод "превозмогать" и придумывать как обойти это. Обнаружение таких мест - повод задуматься о том где мы не туда свернули и исправить это на уровень выше.

[@MyraJKee]

Честно говоря тесты в golang довольно утомительно писать руками. И ценность этих проверок сомнительная. У микросервисов обычно не сильно сложная бизнес-логика. Поэтому иногда кажется что многие тесты пишутся ради тестов.

[@oleganatolievich]

Для времени уже завезли sync Test в Go 1.25

[@FuN_ViT]

Поздравляю.

Теперь вы тестируете свои моки!

Вместо этого стоило проверить, что user.ID!=uuid.Nil (и повторные вызовы CreateUser устанавливают новые значения), а user.CreatedAt>=time.Now (запомненный в начале теста).

[@Sitro23]

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