Тестирование в Go: от плохого к хорошему. Часть 2

[@yuriy1311]

Спасибо за видео! Очень интересно. Хочется продолжение =)

[@СергейКозинский-ж4я]

Спасибо за контент! Хотелось бы продолжения с Docker’ом и GitHub Actions 😊👍

[@alexsh.8080]

Лучшая серия роликов по тестированию какую видел! Сане респект!

[@OdejmosO]

Огонь! Ждем продолжение про е2е с suites!

[@yeu344]

Спасибо за видео! Продолжение будет очень кстати.

[@fellainthewagon7166]

Очень интересно! Ждем продолжения

[@sovrinfo]

Большое спасибо за видео, сделайте еще продолжение!!!

[@АртемТимофеев-я1ы]

Спасибо! Больше go на канале!

[@rumartru]

Спасибо! Лайк не глядя)

[@oleksei3371]

Лайк, подписка. Только я гохой занялся, а тут вы. Бомбически, только вперёд!!

[@yodude2493]

Второй, не глядя лайк! Пацаны, контент топ!

[@Tanya7843]

Спасибо за контент. Хотелось бы инфы с алгоритмами хеширования.

[@D1noZaVRtv]

e2e интересно, ждём

[@unicoxr5tj417]

подписался, лайк.

[@andriipetko8684]

Можно еще BDD тесты разобрать, godog всякие

[@KeyClaim]

Все еще ждем e2e =)

[@ДиасМуратов-в2ы]

то есть, за интеграционные тесты моки тоже могут считаться ?

[@bekzhan356]

Познавательное видео, а есть ссылка на репозиторий?

[@dangbey4822]

топ

[@IV-cz7qw]

Спасибо за обучающие видео! Вы проделали огромную работу! У меня вопрос. Вот тут kzbin.info/www/bejne/fWWWe4CwmbepZpI вы начинаете перебирать варианты неправильного JSON для парсера. На мой взгляд, вы тестируете парсер. Это тестирование внешней зависимости, разве не так?

[@nonesnonoperos9504]

Не совсем. Тестирование парсера просто побочный эффект. Первичная цель - отработать конкретный ошибочный кейс. Можно пойти по простому пути - подсунуть некорректные данные, заодно протестируется анмаршалер. Можно пойти по более сложному - вынести маршалер/анмаршалер как зависимость и замокать его. Усилий больше. Результат теста тот же. Результат на проде хуже (каждый раз при маршалинге/анмаршалинге мы будем ходить в реализацию через таблицу интерфейсов)

[@dmitriylarin2314]

Первый!)

[@ЕвгенийКирьянов-я8ы]

Если бы я так писал тесы, меня бы уволили

[@lqcincinnatus]

1. Судя по названию этого цикла видео ("тестирование от плохого к хорошему"), автор доносит мысль, что Unit-тесты - плохо, интеграционные - лучше, e2e - совсем хорошо. Но в самом видео автор говорит обратное. Прошу пояснить. 2. Как автор относится к вот такой критике пирамиды тестирования kzbin.info/www/bejne/Z2mmhIF3mKpofrs и к подходу, описанному Алексеем в видео?

[@alexandrsakharov629]

Привет, отвечаю: 1. Название здесь иллюстрирует путь нашего репозитория: от непокрытого тестами и падающего от бага, до крепкого и надежного кода. 2. Вы бы тайминг указали :) Промотал видео, Алексей хорошо и прагматично рассказывает про тестирование в разных средах. Пирамида тестирования это просто абстракция и тестирование в нескольких окружениях, конечно, лучше, чем в одном.

[@AlekseyGureiev]

Позволю себе вклиниться. Каждый из типов тестов хорош для своего. В пирамиде тестирования показано условно кол-во тестов каждой категории. Основной критерий того, что e2e тестов меньше всего не в том, что они плохие. Они долгие... потому что проходят весь путь запроса и вовлекают все инфраструктурные элементы (pg, redis, rabbitmq...). Все приложение можно при желании покрыть e2e тестами и coverage будет 100%, но такой набор тестов будет бежать неприемлемо долго. Еще один повод к размышлению -- это то, что в идеале сначала прорабатывается (пишется и тестируется) доменная область и сервисный слой, а уж затем вы подвязываете инфраструктуру. Выходит, что пока у вас нет инфраструктуры (REST API сервера), вы не можете протестировать логику приложения? Если это простой CRUD, то этот период будет очень короток, а если это хорошее приложение с бизнес-правилами, политиками, спецификациями, вы можете провести на этапе бизнес логики много времени. Тут вам пригодятся unit-тесты. И их будет много.

[@aidarlatypov7747]

@@alexandrsakharov629 Да лучше было бы назвать "От простого к сложному"