Юнит тесты нужны не для того, чтобы избавиться от багов. Юнит тесты нужны для валидации того, что после новых изменений все работает как и прежде. А если нет, то мы знаем в каких местах что сломалось. Недавно убирал устаревшую функциональность из кода. Всего было задето немногим больше 90 классов и больше тысячи строк. Когда такое делаешь, то только на юнит тесты молишься. Ибо после таких изменений найти ошибки и исправить без юнит тестов это хуже ада.
@@goriaev согласен с автором, вначале польза небольшая. Но со временем это становится чуть ли не стержнем, вокруг которого держится проект. Когда приходишь на код, который начинали писать ещё наши деды-индусы, то только юнит тестами и живешь
@@bartbelrigvardo5216 понятно, что для hello world-a тесты не нужны. Но тесты нужны впринципе. Я понял основную идею видео, что тесты нужны только в проектах с большой ценой ошибки. И от них больше оверхеда, а польза небольшая. Нашли баг - поправили. С этим я не согласен
согласен, в основном это надо для рефакторинга или правок. и без юнит тестов, если код большой, то лучше не трогать. Но тогда пишутся костыли всякие и т.д.
Это какой-то бред сивой кобылы. "Добавляю функционал не порчу существующий". --- если ты такой гений, то тебе не нужны тесты, тебе не нужны видео на ютьюб, тебе нобелевку пора давать. Когда добавляются функции, когда делается рефакторинг, когда появляются новые входные данные, как убедиться, что ничего не ломается? Юнит-тесты дают, хоть какую-то гарантию.
Зависит от стека технологий и задач. Попробуйте на плюсах низкоуровневые библиотеки под люнух без юнит-тестов пописать. Вопрос даже не в том, когда вы их отладите. Это не в разы дольше, а никогда. Их вообще невозможно без тестов запускать. А писать авто-тесты для UI, да, бессмысленно. Дешевле регресс делать манки тестами по плану тестирования. Уточняйте область, а не категорично обобщайте.
Порой у меня ощущение складывается, что не смотря на то, сколько уже книг написали, сколько роликов про тестирование выложили, всё будет идти по одним и тем же граблям раз за разом. Писать тесты долго и затратно, их часто пишут плохо, их часто просто переписывают из-за ложных срабатываний. Это всё верно, но, это цена которую ты платишь за быстрый отлов регрессии в качестве. Отловить баг в todo листе не составит никаких проблем и без тестов, но стоит тебе взяться за 2-3 годовалый проект, и вся эта мишура про "Нам и без тестов нормального в дебаггере по 2-3 часа сидится" сходит на нет Но честно, я бы и сам не стал прототипировать что-то обкладываясь тестами
Добавлю: если в компилируемых языках часть работы по тестированию выполняет за вас компилятор, то в интерпретируемых никто кроме вас её не сделает. Поэтому юнит-тесты наше всё. С них надо начинать. Сначала пишете тест. Запускаете его. Он падает. Затем допиливаете функционал под этот тест, пока тест не перестаеет падать.
@@programmer78 фронт слишком часто меняется и даже в процессе разработки структура на усмотрение программиста, какой смысл начинать с теста где ты опишешь сколько там должно быть кнопок и что они должны делать?
@@AlexeyProgramming например, могут быть какие-то простые требования с точки зрения дизайна (что кнопки и окошки для ввода текстовой информации должны быть выровнены). Можно сделать структуру фронтенда так, что данные о положении и размерах кнопок будут доступны для тестов. Соответственно, можно сделать тест на эргономичность расположения контролов. Можно сделать тест на то, что контролы не исчезают за границами при изменени размеров окна, при изменении ориентации экрана. Что контролы не наезжают друг на друга. Можно сделать тест на то, что ни один обработчик ни одного из контролов не выполняется дольше определённого времени. Возможно, можно как-то сделать какой-то анализатор кода фронтента и натравливать его на исходный код с целью нахождения ошибок. Всё, сказанное выше - мои догадки, т.к. я ни разу не фронтендер. Более того, возможно эти догадки целесообразны для каких-то больших проектов с большой посещаемостью и нецелесообразны для маленьких проектов, которыми пользуются 5 человек.
Вкратце. Тесты - это вовсе не только про баги. "Юнит-тесты не нужно использовать" - это точно не так. Подробнее - ниже. Кстати, тест на эндпоинт - это скорее ближе к интеграционному тесту, чем к юнит-. Юнит-тесты, как и любые другие тесты - можно вообще не писать, если Вы работаете над проектом в одиночку. Есть резон - почему вообще не делать, могу рассказать подробнее, если интересно. Основной плюс, который не все понимают, от них. В них - скрыты реальные кейсы применения какого-то кода. Когда проект становится достаточно большим, появляется команда - задачи иногда ставятся промежуточные, типа, не реализовать какую-то фичу, а обеспечить промежуточный функционал. В этом случае - тесты - это "наши друзья". Другие разработчики, которые не так хорошо знакомы с кодом и не совсем понимают, что имелось в виду (да и не знают они системы полностью) - могут очень удобно использовать шаблоны в юнит-тестах, чтобы решать эти промежуточные задачи.
Юнит тесты оправданны в случаи разработки большого совта. Если ты работаешь с драйверами, движками и подобным, то юнит тесты - необходимость. Хотя, я согласен, что юнит тесты не нужны для фронта. Я пишу свой яп, и там юнит тесты зачастую спасают. Любое изменение компилятора влачит за собой тонну багов которые нельзя выпускать в прод. Например, у меня один раз сломался логический парсер, он просто не хотел правильно обрабатывать сложные конструкции со скобками and и or. Тогда у меня тесты как раз выручили. P.S. Юнит тесты еще можно использовать для проверки web сервисов. Я обычно их использую для сервисов связанных с бд и подобным.
Как по мне тесты надо писать на сложные юниты, от которых зависит много другого кода и у которых у самих мало зависимостей, для всего остального от юнит тестов больше головной боли чем пользы
По поводу того, что юниты нужны только в банковском софте, давно пользовались продуктами Яндекса? Баг на баге и багом заправляет. Отвратительно, испортились у них все, абсолютно все продукты. Хреново, что они монополисты в такси и доставке еды.
"...Только когда мы пишем софт, который не приемлет никаких ошибок и никаких багов". Нет, друг, для хорошего программиста это не только банковский и медицинский софт. Это любой софт, за который он несёт ответственность. Если программист допустил баг при разработке будильника, врач может проспать важную операцию. Я уже не говорю о практике TDD, когда сначала пишутся тесты, а потом рабочий код. О её пользе написано много статей.
А такой хороший программист в свободное от работы время тесты пишет что ли? Время разработки - это ресурс, и он не далеко бесконечный. За разработку платит бизнес, бизнесу говорят "нам нужны такие-то тесты, они обеспечат то-то то-то, займет столько-то времени сверху. Далее, в зависимости от особенностей предметной области и разрабатываемого софта/части софта, оценивают необходимость, минусы/плюсы и принимают решение. Бизнес может сказать "у нас нет ресурсов на юнит-тесты" даже если они очень желательны и будет прав.
Ну а TDD вообще крайне сомнительная вещь. Ритуал TDD не обязателен для достижения его целей. Из известных мне авторитетных программистов большинство говорили о TDD в негативном ключе и не используют в работе.
Да не важно банк, медицина или любой другой проект. Если на проде есть баг и пользователь это видит, то ему очень неприятно, что он может отказаться от использования проекта. Юнит тесты дают некоторую ганатию, что код работает правильно. А автору нужно учиться. Рано еще вышел в преподы.
Советую почитать Хорикова, принципы Юнит-тестирования, одна из книг которая повлияла на меня очень сильно, все советуют ее почитать, но никто будто и не читал. От себя хочу сказать, под понятием юнит тестов многие подразумевают разное, тесты - тема глубокая, не зря существует отдельная профессия, для того чтобы тестировать что-то, и нет, тестировщики не занимаются ерундой - хороший тестировщик это лучший друг разработчика. Лично я полагаюсь сначала на E2E тесты, потом на функциональные, и чем больший скоуп интеграций они затронут - тем лучше. Потом на юниты, юниты не боюсь выпиливать если они слишком связывают руки на рефакторинге, и превращаются в поток моков. Но так-же активно их пишу, особенно если разрабатываю утилиты или вспомогательные методы
Открою небольшую тайну: компании не проблема нанять 2х, 3х, 10х разработчиков, чтоб тратить больше времени на написание юнит-тестов. А вот когда один разработчик своей правкой вносит баг, который фиксился уже раз 10 и этот баг задерживает релиз - вот это для менеджера проблема. Т.е. юнит тесты - это про то, чтоб обменять немножечко времени на предсказуемость. Кроме того, юнит тесты - это своего рода документация ваших ожиданий относительно того, как функция будет себя вести. Пока юнит тест не упал - можно считать, что такого поведения от функции никто и не ожидает.
Вот ровно об этом же сегодня написал. Прям развернуто. Очень жаль, что на ютуб есть подобные этому видосу. Ведь они кого-то "научат" и потом к тебе такой вот коллега придет и ты будешь думать, как бы ему исправить подходы (((
Я хочу вставить свои пять копеек - нет не "времени". Без юнит тестов разработка завязнет при очередном внесении изменений и никакого выигрыша по времени не получится. Так что на долгой дистанции - сплошной выигрыш
Это у тебя какая-то компания с бесконечным баблом, которая без проблем может взять 2х-10х новых программеров для тестов. А в реальной жизни компания обычно стремится урезать расходы и уменьшить число разрабов. При этом увеличив количество фич, производимых в единицу времени. И в эту схему тесты уже не вписываются.
@@alexblack43 лично я с такой формулировкой не согласен. Я бы сформулировал так, если у компании есть бесконечное бабло, то можно и не тестировать. Проект провалится и деньги будут потеряны. Без должного тестирования любой проект начнет буксовать из-за того, что новые неполадки появляются быстрее, чем исправляются старые. В результате, все программисты забудут про новые фичи и будут исправлять баги.
Конструктивно и без хейта, обратная связь: На минуте 1:50 ты говоришь, что: "он не может учитывать всех сценариев, когда он пишет тесты,, юнит тесты для этой функции. " - это заблуждение. Так как должны учитываться абсолютно все исходы функции или метода которого ты проверяешь юнит тестами . Именно для этого и делаются Юнит тесты. Кстати советую тебе углубляться в тему Юнит Тестов. Ключь в названии. А если добавляется новый функционал с новыми исходами, то тогда и его пркрывают юнит тестами.
Не надо хейтить парнишу, он просто ещё не писал код в команде и не работал над проектами с периодом поддержки дольше 1 месяца. Когда дорастёт до проектов покрупнее сам всё осознает, покраснеет от позора, и сотрёт это видео 😀
Ё-мае, армия челов в комментах не могут быть уверены в своих каталогах без юнит тестов и готовы нанимать аж 10-х разрабов за 1-2 миллиона, чтобы их писать! Как же сильно даст вам прикурить ждущая армия джунов с нейронками, когда выкатят и распиарят стабильный пайплайн для этой адской смеси. Ваши идеологи будут потом точно также писать, что пофиг на код, если все раздроблено и изолированно. Кто работает в условном сбере - вопросов нет, а сеньоры каталожные, тренируйтесь лучше, как прожить на половину зарплаты, а потом на четверть)
главная проблема с которой я чаще всего сталкивался - это разработчики с "тестами головного мозга", по-другому и не скажешь, их хлебом не корми, только дай тесты писать ) это может быть бесконечно правильно, вот только менеджменту на это насрать, так как задача должна быть сделана ещё вчера и в рабочем состоянии
Привет! А как в компаниях дела обстоят с тестами, если это к примеру не банк/медицина, а ты джун? Надо ли будет в них углубиться тому, кто без опыта, перед трудоустройством? Поделись пожалуйста :)
всё обычно: 1) манагерам нужен результаты здесь и сейчас; 2) из-за тестов времени тратится больше, манагерам это не нравится; 3) в лучше случае получится объяснить манагеру, что хоть какие-то тесты нужны, в худшем будешь искать другую работу )
Разработка через тестирование позволяет строить архитектуру компонентов более менее не зависимых друг от друга, а также взаимозаменяемых тобишь полиморфизм, ну думаю и так понятно про что.
Да когда ж школота перестанет писать обучающие ролики... "программист не может предусмотреть все ситуации. " Может и должен. Прэтому методы и разбиваютс на элементарные части. А потом приходит школота с острым желанием все переделать и которая ничего сама предусмотреть не может и единственная защющита от школоты - это юниттесты.
Юнит тесты нужны не для того, чтобы избавиться от багов. Юнит тесты нужны для валидации того, что после новых изменений все работает как и прежде. А если нет, то мы знаем в каких местах что сломалось.
Недавно убирал устаревшую функциональность из кода. Всего было задето немногим больше 90 классов и больше тысячи строк. Когда такое делаешь, то только на юнит тесты молишься. Ибо после таких изменений найти ошибки и исправить без юнит тестов это хуже ада.
Об этом говорится в конце. Но говорится типа это небольшая польза)))
@@goriaev согласен с автором, вначале польза небольшая. Но со временем это становится чуть ли не стержнем, вокруг которого держится проект. Когда приходишь на код, который начинали писать ещё наши деды-индусы, то только юнит тестами и живешь
@@bartbelrigvardo5216 понятно, что для hello world-a тесты не нужны.
Но тесты нужны впринципе. Я понял основную идею видео, что тесты нужны только в проектах с большой ценой ошибки. И от них больше оверхеда, а польза небольшая. Нашли баг - поправили. С этим я не согласен
согласен, в основном это надо для рефакторинга или правок. и без юнит тестов, если код большой, то лучше не трогать. Но тогда пишутся костыли всякие и т.д.
АМИНЬ
Это какой-то бред сивой кобылы. "Добавляю функционал не порчу существующий". --- если ты такой гений, то тебе не нужны тесты, тебе не нужны видео на ютьюб, тебе нобелевку пора давать. Когда добавляются функции, когда делается рефакторинг, когда появляются новые входные данные, как убедиться, что ничего не ломается? Юнит-тесты дают, хоть какую-то гарантию.
Рупор всем дали, а голову всем не дали
Exactly
Почему вы пишете код с багами? Просто пишите с первого раза без багов и всё
Действительно
Зависит от стека технологий и задач. Попробуйте на плюсах низкоуровневые библиотеки под люнух без юнит-тестов пописать. Вопрос даже не в том, когда вы их отладите. Это не в разы дольше, а никогда. Их вообще невозможно без тестов запускать.
А писать авто-тесты для UI, да, бессмысленно. Дешевле регресс делать манки тестами по плану тестирования.
Уточняйте область, а не категорично обобщайте.
Главное, чтобы автора не подпустили к написанию системы управления ядерным реактором.
Порой у меня ощущение складывается, что не смотря на то, сколько уже книг написали, сколько роликов про тестирование выложили, всё будет идти по одним и тем же граблям раз за разом.
Писать тесты долго и затратно, их часто пишут плохо, их часто просто переписывают из-за ложных срабатываний. Это всё верно, но, это цена которую ты платишь за быстрый отлов регрессии в качестве. Отловить баг в todo листе не составит никаких проблем и без тестов, но стоит тебе взяться за 2-3 годовалый проект, и вся эта мишура про "Нам и без тестов нормального в дебаггере по 2-3 часа сидится" сходит на нет
Но честно, я бы и сам не стал прототипировать что-то обкладываясь тестами
Добавлю: если в компилируемых языках часть работы по тестированию выполняет за вас компилятор, то в интерпретируемых никто кроме вас её не сделает.
Поэтому юнит-тесты наше всё. С них надо начинать. Сначала пишете тест. Запускаете его. Он падает. Затем допиливаете функционал под этот тест, пока тест не перестаеет падать.
TDD только для бэкенда подходит где есть чёткая формализация задачи и поведения
@@AlexeyProgramming я не программировал для вэба, но мне кажется, фронтенд можно так написать, чтоб он был в каком-то виде тестируемым.
@@programmer78 фронт слишком часто меняется и даже в процессе разработки структура на усмотрение программиста, какой смысл начинать с теста где ты опишешь сколько там должно быть кнопок и что они должны делать?
@@AlexeyProgramming например, могут быть какие-то простые требования с точки зрения дизайна (что кнопки и окошки для ввода текстовой информации должны быть выровнены).
Можно сделать структуру фронтенда так, что данные о положении и размерах кнопок будут доступны для тестов. Соответственно, можно сделать тест на эргономичность расположения контролов. Можно сделать тест на то, что контролы не исчезают за границами при изменени размеров окна, при изменении ориентации экрана. Что контролы не наезжают друг на друга.
Можно сделать тест на то, что ни один обработчик ни одного из контролов не выполняется дольше определённого времени.
Возможно, можно как-то сделать какой-то анализатор кода фронтента и натравливать его на исходный код с целью нахождения ошибок.
Всё, сказанное выше - мои догадки, т.к. я ни разу не фронтендер. Более того, возможно эти догадки целесообразны для каких-то больших проектов с большой посещаемостью и нецелесообразны для маленьких проектов, которыми пользуются 5 человек.
Вкратце. Тесты - это вовсе не только про баги. "Юнит-тесты не нужно использовать" - это точно не так. Подробнее - ниже. Кстати, тест на эндпоинт - это скорее ближе к интеграционному тесту, чем к юнит-.
Юнит-тесты, как и любые другие тесты - можно вообще не писать, если Вы работаете над проектом в одиночку. Есть резон - почему вообще не делать, могу рассказать подробнее, если интересно.
Основной плюс, который не все понимают, от них. В них - скрыты реальные кейсы применения какого-то кода. Когда проект становится достаточно большим, появляется команда - задачи иногда ставятся промежуточные, типа, не реализовать какую-то фичу, а обеспечить промежуточный функционал.
В этом случае - тесты - это "наши друзья". Другие разработчики, которые не так хорошо знакомы с кодом и не совсем понимают, что имелось в виду (да и не знают они системы полностью) - могут очень удобно использовать шаблоны в юнит-тестах, чтобы решать эти промежуточные задачи.
Юнит тесты оправданны в случаи разработки большого совта. Если ты работаешь с драйверами, движками и подобным, то юнит тесты - необходимость. Хотя, я согласен, что юнит тесты не нужны для фронта.
Я пишу свой яп, и там юнит тесты зачастую спасают. Любое изменение компилятора влачит за собой тонну багов которые нельзя выпускать в прод. Например, у меня один раз сломался логический парсер, он просто не хотел правильно обрабатывать сложные конструкции со скобками and и or. Тогда у меня тесты как раз выручили.
P.S. Юнит тесты еще можно использовать для проверки web сервисов. Я обычно их использую для сервисов связанных с бд и подобным.
Как по мне тесты надо писать на сложные юниты, от которых зависит много другого кода и у которых у самих мало зависимостей, для всего остального от юнит тестов больше головной боли чем пользы
is this such a trick: to say stupid things to make others write more comments? I'm in...
По поводу того, что юниты нужны только в банковском софте, давно пользовались продуктами Яндекса? Баг на баге и багом заправляет. Отвратительно, испортились у них все, абсолютно все продукты. Хреново, что они монополисты в такси и доставке еды.
А что за рисовалка используется?
"...Только когда мы пишем софт, который не приемлет никаких ошибок и никаких багов". Нет, друг, для хорошего программиста это не только банковский и медицинский софт. Это любой софт, за который он несёт ответственность. Если программист допустил баг при разработке будильника, врач может проспать важную операцию. Я уже не говорю о практике TDD, когда сначала пишутся тесты, а потом рабочий код. О её пользе написано много статей.
о вреде и бредовости TDD написано статей не меньше, так что не аргумент
А такой хороший программист в свободное от работы время тесты пишет что ли? Время разработки - это ресурс, и он не далеко бесконечный. За разработку платит бизнес, бизнесу говорят "нам нужны такие-то тесты, они обеспечат то-то то-то, займет столько-то времени сверху. Далее, в зависимости от особенностей предметной области и разрабатываемого софта/части софта, оценивают необходимость, минусы/плюсы и принимают решение. Бизнес может сказать "у нас нет ресурсов на юнит-тесты" даже если они очень желательны и будет прав.
Ну а TDD вообще крайне сомнительная вещь. Ритуал TDD не обязателен для достижения его целей. Из известных мне авторитетных программистов большинство говорили о TDD в негативном ключе и не используют в работе.
Да не важно банк, медицина или любой другой проект. Если на проде есть баг и пользователь это видит, то ему очень неприятно, что он может отказаться от использования проекта. Юнит тесты дают некоторую ганатию, что код работает правильно.
А автору нужно учиться. Рано еще вышел в преподы.
Советую почитать Хорикова, принципы Юнит-тестирования, одна из книг которая повлияла на меня очень сильно, все советуют ее почитать, но никто будто и не читал.
От себя хочу сказать, под понятием юнит тестов многие подразумевают разное, тесты - тема глубокая, не зря существует отдельная профессия, для того чтобы тестировать что-то, и нет, тестировщики не занимаются ерундой - хороший тестировщик это лучший друг разработчика.
Лично я полагаюсь сначала на E2E тесты, потом на функциональные, и чем больший скоуп интеграций они затронут - тем лучше.
Потом на юниты, юниты не боюсь выпиливать если они слишком связывают руки на рефакторинге, и превращаются в поток моков.
Но так-же активно их пишу, особенно если разрабатываю утилиты или вспомогательные методы
А еще, юниты которые взрываются на рефакторинге а не проверяют баги - печалька, это либо проблемы с модульностью и качеством кода, либо подходом
Открою небольшую тайну: компании не проблема нанять 2х, 3х, 10х разработчиков, чтоб тратить больше времени на написание юнит-тестов.
А вот когда один разработчик своей правкой вносит баг, который фиксился уже раз 10 и этот баг задерживает релиз - вот это для менеджера проблема.
Т.е. юнит тесты - это про то, чтоб обменять немножечко времени на предсказуемость.
Кроме того, юнит тесты - это своего рода документация ваших ожиданий относительно того, как функция будет себя вести. Пока юнит тест не упал - можно считать, что такого поведения от функции никто и не ожидает.
Вот ровно об этом же сегодня написал. Прям развернуто.
Очень жаль, что на ютуб есть подобные этому видосу. Ведь они кого-то "научат" и потом к тебе такой вот коллега придет и ты будешь думать, как бы ему исправить подходы (((
Я хочу вставить свои пять копеек - нет не "времени". Без юнит тестов разработка завязнет при очередном внесении изменений и никакого выигрыша по времени не получится. Так что на долгой дистанции - сплошной выигрыш
Чет представил миньонов, которые сидят и юнит тестами код покрывают.
Это у тебя какая-то компания с бесконечным баблом, которая без проблем может взять 2х-10х новых программеров для тестов. А в реальной жизни компания обычно стремится урезать расходы и уменьшить число разрабов. При этом увеличив количество фич, производимых в единицу времени. И в эту схему тесты уже не вписываются.
@@alexblack43 лично я с такой формулировкой не согласен. Я бы сформулировал так, если у компании есть бесконечное бабло, то можно и не тестировать. Проект провалится и деньги будут потеряны.
Без должного тестирования любой проект начнет буксовать из-за того, что новые неполадки появляются быстрее, чем исправляются старые. В результате, все программисты забудут про новые фичи и будут исправлять баги.
Это видео - юнит тест к юнит тестам
Конструктивно и без хейта, обратная связь:
На минуте 1:50 ты говоришь, что: "он не может учитывать всех сценариев, когда он пишет тесты,, юнит тесты для этой функции. " - это заблуждение. Так как должны учитываться абсолютно все исходы функции или метода которого ты проверяешь юнит тестами . Именно для этого и делаются Юнит тесты. Кстати советую тебе углубляться в тему Юнит Тестов. Ключь в названии.
А если добавляется новый функционал с новыми исходами, то тогда и его пркрывают юнит тестами.
В общем случае невозможно учесть все исходы. Например, если функция складывает два числа, то пришлось бы писать тест со всеми комбинациями чисел.
Видео очень крутое, продолжай! Можешь убрать высокие частоты звука? Уши режет
Не надо хейтить парнишу, он просто ещё не писал код в команде и не работал над проектами с периодом поддержки дольше 1 месяца. Когда дорастёт до проектов покрупнее сам всё осознает, покраснеет от позора, и сотрёт это видео 😀
Ё-мае, армия челов в комментах не могут быть уверены в своих каталогах без юнит тестов и готовы нанимать аж 10-х разрабов за 1-2 миллиона, чтобы их писать! Как же сильно даст вам прикурить ждущая армия джунов с нейронками, когда выкатят и распиарят стабильный пайплайн для этой адской смеси. Ваши идеологи будут потом точно также писать, что пофиг на код, если все раздроблено и изолированно. Кто работает в условном сбере - вопросов нет, а сеньоры каталожные, тренируйтесь лучше, как прожить на половину зарплаты, а потом на четверть)
Хотел поставить дизлайк, так как для меня это филькина грамота и зачем я тут не понял, но ... лайков всего 15.
Жаль этого добряка...
да, человек старался, диаграммы рисовал, видео записывал... просто он забыл подумать перед этим или опыт небольшой
Что вместо unit-тестов, вазелин?
главная проблема с которой я чаще всего сталкивался - это разработчики с "тестами головного мозга", по-другому и не скажешь, их хлебом не корми, только дай тесты писать )
это может быть бесконечно правильно, вот только менеджменту на это насрать, так как задача должна быть сделана ещё вчера и в рабочем состоянии
Так что за рисовалку автор использует?
Пирамида тестирования.
В какой проге он рисует?
Жаль, что не был подписан на тебя. Теперь не смогу отписаться.
Понятно, мы вам перезвоним
Привет! А как в компаниях дела обстоят с тестами, если это к примеру не банк/медицина, а ты джун?
Надо ли будет в них углубиться тому, кто без опыта, перед трудоустройством?
Поделись пожалуйста :)
всё обычно:
1) манагерам нужен результаты здесь и сейчас;
2) из-за тестов времени тратится больше, манагерам это не нравится;
3) в лучше случае получится объяснить манагеру, что хоть какие-то тесты нужны, в худшем будешь искать другую работу )
Я пишу юнит тесты на контроллеры, чтобы проверять запросы не через постман как идиот
Разработка через тестирование позволяет строить архитектуру компонентов более менее не зависимых друг от друга, а также взаимозаменяемых тобишь полиморфизм, ну думаю и так понятно про что.
Да когда ж школота перестанет писать обучающие ролики... "программист не может предусмотреть все ситуации. " Может и должен. Прэтому методы и разбиваютс на элементарные части. А потом приходит школота с острым желанием все переделать и которая ничего сама предусмотреть не может и единственная защющита от школоты - это юниттесты.
прежде чем выложить видео у автора не прошли валидацию юнит тесты с реальными примерами, но прошли с воздушными func A...B...C
Отличный видос, спасибо за информацию!
Боже какая чушь.