Спасибо за обучающие видео! Вы проделали огромную работу! У меня вопрос. Вот тут ua-cam.com/video/G43JMzdRv00/v-deo.html вы начинаете перебирать варианты неправильного JSON для парсера. На мой взгляд, вы тестируете парсер. Это тестирование внешней зависимости, разве не так?
Не совсем. Тестирование парсера просто побочный эффект. Первичная цель - отработать конкретный ошибочный кейс. Можно пойти по простому пути - подсунуть некорректные данные, заодно протестируется анмаршалер. Можно пойти по более сложному - вынести маршалер/анмаршалер как зависимость и замокать его. Усилий больше. Результат теста тот же. Результат на проде хуже (каждый раз при маршалинге/анмаршалинге мы будем ходить в реализацию через таблицу интерфейсов)
1. Судя по названию этого цикла видео ("тестирование от плохого к хорошему"), автор доносит мысль, что Unit-тесты - плохо, интеграционные - лучше, e2e - совсем хорошо. Но в самом видео автор говорит обратное. Прошу пояснить. 2. Как автор относится к вот такой критике пирамиды тестирования ua-cam.com/video/18CSNAcE5HY/v-deo.html и к подходу, описанному Алексеем в видео?
Привет, отвечаю: 1. Название здесь иллюстрирует путь нашего репозитория: от непокрытого тестами и падающего от бага, до крепкого и надежного кода. 2. Вы бы тайминг указали :) Промотал видео, Алексей хорошо и прагматично рассказывает про тестирование в разных средах. Пирамида тестирования это просто абстракция и тестирование в нескольких окружениях, конечно, лучше, чем в одном.
Позволю себе вклиниться. Каждый из типов тестов хорош для своего. В пирамиде тестирования показано условно кол-во тестов каждой категории. Основной критерий того, что e2e тестов меньше всего не в том, что они плохие. Они долгие... потому что проходят весь путь запроса и вовлекают все инфраструктурные элементы (pg, redis, rabbitmq...). Все приложение можно при желании покрыть e2e тестами и coverage будет 100%, но такой набор тестов будет бежать неприемлемо долго. Еще один повод к размышлению -- это то, что в идеале сначала прорабатывается (пишется и тестируется) доменная область и сервисный слой, а уж затем вы подвязываете инфраструктуру. Выходит, что пока у вас нет инфраструктуры (REST API сервера), вы не можете протестировать логику приложения? Если это простой CRUD, то этот период будет очень короток, а если это хорошее приложение с бизнес-правилами, политиками, спецификациями, вы можете провести на этапе бизнес логики много времени. Тут вам пригодятся unit-тесты. И их будет много.
Лучшая серия роликов по тестированию какую видел! Сане респект!
Спасибо за видео! Очень интересно. Хочется продолжение =)
Спасибо за видео! Продолжение будет очень кстати.
Огонь! Ждем продолжение про е2е с suites!
Спасибо за контент! Хотелось бы продолжения с Docker’ом и GitHub Actions 😊👍
Очень интересно! Ждем продолжения
Большое спасибо за видео, сделайте еще продолжение!!!
Лайк, подписка. Только я гохой занялся, а тут вы. Бомбически, только вперёд!!
Спасибо! Больше go на канале!
Спасибо за контент. Хотелось бы инфы с алгоритмами хеширования.
Спасибо! Лайк не глядя)
Второй, не глядя лайк! Пацаны, контент топ!
e2e интересно, ждём
Можно еще BDD тесты разобрать, godog всякие
подписался, лайк.
Познавательное видео, а есть ссылка на репозиторий?
Все еще ждем e2e =)
то есть, за интеграционные тесты моки тоже могут считаться ?
Спасибо за обучающие видео! Вы проделали огромную работу!
У меня вопрос. Вот тут ua-cam.com/video/G43JMzdRv00/v-deo.html вы начинаете перебирать варианты неправильного JSON для парсера. На мой взгляд, вы тестируете парсер. Это тестирование внешней зависимости, разве не так?
Не совсем. Тестирование парсера просто побочный эффект.
Первичная цель - отработать конкретный ошибочный кейс.
Можно пойти по простому пути - подсунуть некорректные данные, заодно протестируется анмаршалер.
Можно пойти по более сложному - вынести маршалер/анмаршалер как зависимость и замокать его.
Усилий больше. Результат теста тот же. Результат на проде хуже (каждый раз при маршалинге/анмаршалинге мы будем ходить в реализацию через таблицу интерфейсов)
топ
Первый!)
Если бы я так писал тесы, меня бы уволили
1. Судя по названию этого цикла видео ("тестирование от плохого к хорошему"), автор доносит мысль, что Unit-тесты - плохо, интеграционные - лучше, e2e - совсем хорошо. Но в самом видео автор говорит обратное. Прошу пояснить.
2. Как автор относится к вот такой критике пирамиды тестирования ua-cam.com/video/18CSNAcE5HY/v-deo.html и к подходу, описанному Алексеем в видео?
Привет, отвечаю:
1. Название здесь иллюстрирует путь нашего репозитория: от непокрытого тестами и падающего от бага, до крепкого и надежного кода.
2. Вы бы тайминг указали :) Промотал видео, Алексей хорошо и прагматично рассказывает про тестирование в разных средах. Пирамида тестирования это просто абстракция и тестирование в нескольких окружениях, конечно, лучше, чем в одном.
Позволю себе вклиниться. Каждый из типов тестов хорош для своего. В пирамиде тестирования показано условно кол-во тестов каждой категории. Основной критерий того, что e2e тестов меньше всего не в том, что они плохие. Они долгие... потому что проходят весь путь запроса и вовлекают все инфраструктурные элементы (pg, redis, rabbitmq...). Все приложение можно при желании покрыть e2e тестами и coverage будет 100%, но такой набор тестов будет бежать неприемлемо долго. Еще один повод к размышлению -- это то, что в идеале сначала прорабатывается (пишется и тестируется) доменная область и сервисный слой, а уж затем вы подвязываете инфраструктуру. Выходит, что пока у вас нет инфраструктуры (REST API сервера), вы не можете протестировать логику приложения? Если это простой CRUD, то этот период будет очень короток, а если это хорошее приложение с бизнес-правилами, политиками, спецификациями, вы можете провести на этапе бизнес логики много времени. Тут вам пригодятся unit-тесты. И их будет много.
@@alexandrsakharov629 Да лучше было бы назвать "От простого к сложному"