до того, как вам реально понадобятся параллельные юнит-тесты(которые еще в testify/suite хрен сделаешь), миллион строчек кода пройдет
В го же они, вроде, по дефолту параллельно запускаются через go test ./..
Ничего не мешает запускать несколько suite-ов параллельно
Также ничего не мешает сделать go test -p 1 и не париться тот самый миллион строчек. Если есть интеграционные тесты с настоящей базой, это вообще практически мастхев во многих случаях.
А можно просто раскурить google/wire и не юзать глобалы)))
Я эту проблему обошёл двумя способами: созданием через create database или запуском ещё одного инстанса (с ограничением в -p)
все равно в какой-то момент у тебя появятся тесты с миграцией и придется их либо в один пакадж совать, либо -p 1
Тесты с миграцией - это явно не юниты
все равно они в _test лежат и запускаютя как юниты
Это не нормально, нужно иметь возможность делить тесты на группы для раздельного запуска
это все теоретически нужно на очень больших проектах
Для этого можно использовать билд теги
Нет, это нужно везде, если у вас есть разные виды тестов. Потому что приёмочные тесты могут достаточно медленно выполняться, а юниты очень быстрые. Т.е. в большинстве случаев всё равно гонять будешь юниты
ничего не знаю, у меня в основной сюите интеграхи и юниты. спокойно накатываются, поднимают в докере базочку, все быстро и ровно, не вижу причин разделять.
Почему?
На стадии интциализации, нескольких объектов, достаточно сделать фатал в любом из них, и выйти из приложения если хоть в одном объекте поймали ошибку. Зачем тут контейнер вообще не понятно.
Чтобы не юзать глобалы и иметь возможность нормально мокать в тестах
А где у нас глобалы? Единственный вариант, что саму функцию main, не протестируем.
https://t.me/gogolang/604302
А, ну это у него. У мну такого нет. У мну тырфесы, моки, юнит тесты...
Обсуждают сегодня