постарел в плане?

не комитили давно

ну хз куда его можно улучшать)

согласен

Ууид хорош тем, что он не требует знать какие раньше идентификаторы были сгенерены, ТК у него огромный диапазон.
Если же вы будете проверять предыдущие сгенеренные идентификаторы, то можете например, получать любой хеш, главное чтобы хватило на много ссылок.

мне не нужен uuid, нужна любая уникальная строка и ничего больше) условно говоря как ключ в редис положил и забыл

Так они сейчас сделали postgREST, это ещё круче

Так сделайте рандомное число в нужном вам диапазоне. Потом конвертните его к нужному словарю (добавьте использование букв, если надо).
Ууид ровно так и работает, просто там очень большое число генерится.

что дальше? postgraphql для поддержки запроса с join-ами??

так уже

PostGraphile

Видимо дальше postGrpc ну и т. д.

отвечая на сам себе заданный вопрос go-junit-report умеет принимать на вход и выхлоп с -json, что делает его парсер несколько надёжнее

Я тут недавно столкнулся с https://labix.org/gocheck который вообще несовместим со стандартным форматом вывода. Вот где безумие и отчаяние. Т.к. тестов несколько тысяч, а чтобы их переписать надо несколько месяцев работы всей команды. А без переписывания невозможно построить нормальные отчеты... А ну и проект конечно же забршен и его не мэйнтейнят.

Ох, не надо такое использовать...

Ну это мне надо было попасть в компанию лет 5 назад (или раньше) и сказать им об этом... Это самое очевидное решение. А теперь я ищу решение, как же это автоматически отрефакторить, чтобы и не сломать и при этом заменить все на тот же testify. Это скорее всего можно сделать используя  AST и написав кастомную утилиту которая пройдется по коду и заменит одни куски кода другими (по хитрым правилам), но я в этом абсолютный профан, поэтому пока что все печально.

Оно бы и ничего, но тестировать это всё отвратительно, и ломается из-за убогого дин. языка достаточно часто

можно обмазываться интеграционными тестами
но вообще согласен

через vet tool можно наверное