Go-тесты: путь к надежному коду

[Chelyuk]

Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему.
Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.

[Nikstrong]

Спасибо, согласен - часто тоже такое встречаю. Но потом, когда команда поймет, сэкономит много времени.

[QtRoS]

Присоединяюсь, довольно приятно описана база. Можно использовать как обучение и для начинающих Go-разработчиков, и для новоприбывших из других языков/технологий.

[Nikstrong]

Спасибо, очень приятно! Надеюсь, что статья может быть полезна и тем, кто только начинает с Go, и тем, кто пришёл из других языков. Именно такую цель и ставил - сделать материал понятным и прикладным.

[vsting]

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

[Nikstrong]

Да, это правда. Часто осознание ценности тестов приходит через боль. А ещё многим командам тесты кажутся рутиной - на них жаль времени, особенно когда поджимают сроки и давят менеджеры. В такие моменты хочется просто успеть вовремя - даже если без тестов.

[sevnight]

На верхнем уровне — end‑to‑end тесты...

Нужны они не всегда, но очень пригодятся, когда важна не только внутренняя логика, но и то, как выглядит система «снаружи».

Ваши слова да всем бы в уши. В реальности пирамида часто перевёрнутая, или какая‑то ещё. И e2e нужны в не малом количестве. Иногда речь не только про "как выглядит", но и про то что на фронте могут быть "зашиты" бизнес процессы.

Эх, хорошо когда разработчики пишут юнит‑тесты... =) Здоровая практика, когда все уровни покрываются. Разработка пишет юнит‑тесты, а тестирование — e2e. Интеграционные — можно договориться как поделить ответственность.

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

Вы абсолютно правы. Разрабатываемые автотесты, так или иначе, должны проверяться. Будь то юниты или интеграционные, или e2e.

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

[Nikstrong]

Спасибо! Выбора языка для покрытия нижней части пирамиды, зависит от проекта и целей, но чаще действительно используют тот же стек, это проще и логичнее для поддержки