Юнит тесты нужны не для того, чтобы избавиться от багов. Юнит тесты нужны для валидации того, что после новых изменений все работает как и прежде. А если нет, то мы знаем в каких местах что сломалось. Недавно убирал устаревшую функциональность из кода. Всего было задето немногим больше 90 классов и больше тысячи строк. Когда такое делаешь, то только на юнит тесты молишься. Ибо после таких изменений найти ошибки и исправить без юнит тестов это хуже ада.
@goriaev
29 күн бұрын
Об этом говорится в конце. Но говорится типа это небольшая польза)))
@bartbelrigvardo5216
29 күн бұрын
@@goriaev согласен с автором, вначале польза небольшая. Но со временем это становится чуть ли не стержнем, вокруг которого держится проект. Когда приходишь на код, который начинали писать ещё наши деды-индусы, то только юнит тестами и живешь
@goriaev
29 күн бұрын
@@bartbelrigvardo5216 понятно, что для hello world-a тесты не нужны. Но тесты нужны впринципе. Я понял основную идею видео, что тесты нужны только в проектах с большой ценой ошибки. И от них больше оверхеда, а польза небольшая. Нашли баг - поправили. С этим я не согласен
@MichaelKondrashin28 күн бұрын
Это какой-то бред сивой кобылы. "Добавляю функционал не порчу существующий". --- если ты такой гений, то тебе не нужны тесты, тебе не нужны видео на ютьюб, тебе нобелевку пора давать. Когда добавляются функции, когда делается рефакторинг, когда появляются новые входные данные, как убедиться, что ничего не ломается? Юнит-тесты дают, хоть какую-то гарантию.
@chikenmacnugget28 күн бұрын
Рупор всем дали, а голову всем не дали
@user-rp3fc4dh7c
28 күн бұрын
Exactly
@user-hw4ng1hk4y29 күн бұрын
Зависит от стека технологий и задач. Попробуйте на плюсах низкоуровневые библиотеки под люнух без юнит-тестов пописать. Вопрос даже не в том, когда вы их отладите. Это не в разы дольше, а никогда. Их вообще невозможно без тестов запускать. А писать авто-тесты для UI, да, бессмысленно. Дешевле регресс делать манки тестами по плану тестирования. Уточняйте область, а не категорично обобщайте.
@banzaika25 күн бұрын
Видео очень крутое, продолжай! Можешь убрать высокие частоты звука? Уши режет
@DaddyTorque28 күн бұрын
Добавлю: если в компилируемых языках часть работы по тестированию выполняет за вас компилятор, то в интерпретируемых никто кроме вас её не сделает. Поэтому юнит-тесты наше всё. С них надо начинать. Сначала пишете тест. Запускаете его. Он падает. Затем допиливаете функционал под этот тест, пока тест не перестаеет падать.
@AlexeyProgramming
27 күн бұрын
TDD только для бэкенда подходит где есть чёткая формализация задачи и поведения
@DaddyTorque
27 күн бұрын
@@AlexeyProgramming я не программировал для вэба, но мне кажется, фронтенд можно так написать, чтоб он был в каком-то виде тестируемым.
@AlexeyProgramming
27 күн бұрын
@@DaddyTorque фронт слишком часто меняется и даже в процессе разработки структура на усмотрение программиста, какой смысл начинать с теста где ты опишешь сколько там должно быть кнопок и что они должны делать?
@DaddyTorque
23 күн бұрын
@@AlexeyProgramming например, могут быть какие-то простые требования с точки зрения дизайна (что кнопки и окошки для ввода текстовой информации должны быть выровнены). Можно сделать структуру фронтенда так, что данные о положении и размерах кнопок будут доступны для тестов. Соответственно, можно сделать тест на эргономичность расположения контролов. Можно сделать тест на то, что контролы не исчезают за границами при изменени размеров окна, при изменении ориентации экрана. Что контролы не наезжают друг на друга. Можно сделать тест на то, что ни один обработчик ни одного из контролов не выполняется дольше определённого времени. Возможно, можно как-то сделать какой-то анализатор кода фронтента и натравливать его на исходный код с целью нахождения ошибок. Всё, сказанное выше - мои догадки, т.к. я ни разу не фронтендер. Более того, возможно эти догадки целесообразны для каких-то больших проектов с большой посещаемостью и нецелесообразны для маленьких проектов, которыми пользуются 5 человек.
@enmaboya26 күн бұрын
главная проблема с которой я чаще всего сталкивался - это разработчики с "тестами головного мозга", по-другому и не скажешь, их хлебом не корми, только дай тесты писать ) это может быть бесконечно правильно, вот только менеджменту на это насрать, так как задача должна быть сделана ещё вчера и в рабочем состоянии
@Username-xy6sy27 күн бұрын
Почему вы пишете код с багами? Просто пишите с первого раза без багов и всё
@scarlatum27 күн бұрын
Порой у меня ощущение складывается, что не смотря на то, сколько уже книг написали, сколько роликов про тестирование выложили, всё будет идти по одним и тем же граблям раз за разом. Писать тесты долго и затратно, их часто пишут плохо, их часто просто переписывают из-за ложных срабатываний. Это всё верно, но, это цена которую ты платишь за быстрый отлов регрессии в качестве. Отловить баг в todo листе не составит никаких проблем и без тестов, но стоит тебе взяться за 2-3 годовалый проект, и вся эта мишура про "Нам и без тестов нормального в дебаггере по 2-3 часа сидится" сходит на нет Но честно, я бы и сам не стал прототипировать что-то обкладываясь тестами
@romreriogd97827 күн бұрын
Юнит тесты оправданны в случаи разработки большого совта. Если ты работаешь с драйверами, движками и подобным, то юнит тесты - необходимость. Хотя, я согласен, что юнит тесты не нужны для фронта. Я пишу свой яп, и там юнит тесты зачастую спасают. Любое изменение компилятора влачит за собой тонну багов которые нельзя выпускать в прод. Например, у меня один раз сломался логический парсер, он просто не хотел правильно обрабатывать сложные конструкции со скобками and и or. Тогда у меня тесты как раз выручили. P.S. Юнит тесты еще можно использовать для проверки web сервисов. Я обычно их использую для сервисов связанных с бд и подобным.
@jgkdmdevienjjgg886628 күн бұрын
Как по мне тесты надо писать на сложные юниты, от которых зависит много другого кода и у которых у самих мало зависимостей, для всего остального от юнит тестов больше головной боли чем пользы
@hpc83229 күн бұрын
Привет! А как в компаниях дела обстоят с тестами, если это к примеру не банк/медицина, а ты джун? Надо ли будет в них углубиться тому, кто без опыта, перед трудоустройством? Поделись пожалуйста :)
@enmaboya
26 күн бұрын
всё обычно: 1) манагерам нужен результаты здесь и сейчас; 2) из-за тестов времени тратится больше, манагерам это не нравится; 3) в лучше случае получится объяснить манагеру, что хоть какие-то тесты нужны, в худшем будешь искать другую работу )
@nevaknowmanamesame508928 күн бұрын
По поводу того, что юниты нужны только в банковском софте, давно пользовались продуктами Яндекса? Баг на баге и багом заправляет. Отвратительно, испортились у них все, абсолютно все продукты. Хреново, что они монополисты в такси и доставке еды.
@pavelbasmanov219229 күн бұрын
Советую почитать Хорикова, принципы Юнит-тестирования, одна из книг которая повлияла на меня очень сильно, все советуют ее почитать, но никто будто и не читал. От себя хочу сказать, под понятием юнит тестов многие подразумевают разное, тесты - тема глубокая, не зря существует отдельная профессия, для того чтобы тестировать что-то, и нет, тестировщики не занимаются ерундой - хороший тестировщик это лучший друг разработчика. Лично я полагаюсь сначала на E2E тесты, потом на функциональные, и чем больший скоуп интеграций они затронут - тем лучше. Потом на юниты, юниты не боюсь выпиливать если они слишком связывают руки на рефакторинге, и превращаются в поток моков. Но так-же активно их пишу, особенно если разрабатываю утилиты или вспомогательные методы
@pavelbasmanov2192
29 күн бұрын
А еще, юниты которые взрываются на рефакторинге а не проверяют баги - печалька, это либо проблемы с модульностью и качеством кода, либо подходом
@user-tt3yw5vv5n28 күн бұрын
is this such a trick: to say stupid things to make others write more comments? I'm in...
@ebasher79528 күн бұрын
Конструктивно и без хейта, обратная связь: На минуте 1:50 ты говоришь, что: "он не может учитывать всех сценариев, когда он пишет тесты,, юнит тесты для этой функции. " - это заблуждение. Так как должны учитываться абсолютно все исходы функции или метода которого ты проверяешь юнит тестами . Именно для этого и делаются Юнит тесты. Кстати советую тебе углубляться в тему Юнит Тестов. Ключь в названии. А если добавляется новый функционал с новыми исходами, то тогда и его пркрывают юнит тестами.
@vilivermb
27 күн бұрын
В общем случае невозможно учесть все исходы. Например, если функция складывает два числа, то пришлось бы писать тест со всеми комбинациями чисел.
@saitaro27 күн бұрын
"...Только когда мы пишем софт, который не приемлет никаких ошибок и никаких багов". Нет, друг, для хорошего программиста это не только банковский и медицинский софт. Это любой софт, за который он несёт ответственность. Если программист допустил баг при разработке будильника, врач может проспать важную операцию. Я уже не говорю о практике TDD, когда сначала пишутся тесты, а потом рабочий код. О её пользе написано много статей.
@enmaboya
26 күн бұрын
о вреде и бредовости TDD написано статей не меньше, так что не аргумент
@nevaknowmanamesame508928 күн бұрын
Пирамида тестирования.
@aKlnv26 күн бұрын
В какой проге он рисует?
@manokubamba622928 күн бұрын
Хотел поставить дизлайк, так как для меня это филькина грамота и зачем я тут не понял, но ... лайков всего 15. Жаль этого добряка...
@user-rp3fc4dh7c
28 күн бұрын
да, человек старался, диаграммы рисовал, видео записывал... просто он забыл подумать перед этим или опыт небольшой
@user-er6zr1tm3i27 күн бұрын
Что вместо unit-тестов, вазелин?
@DaddyTorque29 күн бұрын
Открою небольшую тайну: компании не проблема нанять 2х, 3х, 10х разработчиков, чтоб тратить больше времени на написание юнит-тестов. А вот когда один разработчик своей правкой вносит баг, который фиксился уже раз 10 и этот баг задерживает релиз - вот это для менеджера проблема. Т.е. юнит тесты - это про то, чтоб обменять немножечко времени на предсказуемость. Кроме того, юнит тесты - это своего рода документация ваших ожиданий относительно того, как функция будет себя вести. Пока юнит тест не упал - можно считать, что такого поведения от функции никто и не ожидает.
@ntvisigoth
29 күн бұрын
Вот ровно об этом же сегодня написал. Прям развернуто. Очень жаль, что на ютуб есть подобные этому видосу. Ведь они кого-то "научат" и потом к тебе такой вот коллега придет и ты будешь думать, как бы ему исправить подходы (((
@MichaelKondrashin
28 күн бұрын
Я хочу вставить свои пять копеек - нет не "времени". Без юнит тестов разработка завязнет при очередном внесении изменений и никакого выигрыша по времени не получится. Так что на долгой дистанции - сплошной выигрыш
@TheMrArmbull27 күн бұрын
прежде чем выложить видео у автора не прошли валидацию юнит тесты с реальными примерами, но прошли с воздушными func A...B...C
@bot_detector27 күн бұрын
Понятно, мы вам перезвоним
@AlexeyProgramming27 күн бұрын
Не надо хейтить парнишу, он просто ещё не писал код в команде и не работал над проектами с периодом поддержки дольше 1 месяца. Когда дорастёт до проектов покрупнее сам всё осознает, покраснеет от позора, и сотрёт это видео 😀
@bbbb-me6vm27 күн бұрын
Да когда ж школота перестанет писать обучающие ролики... "программист не может предусмотреть все ситуации. " Может и должен. Прэтому методы и разбиваютс на элементарные части. А потом приходит школота с острым желанием все переделать и которая ничего сама предусмотреть не может и единственная защющита от школоты - это юниттесты.
Пікірлер: 44
Юнит тесты нужны не для того, чтобы избавиться от багов. Юнит тесты нужны для валидации того, что после новых изменений все работает как и прежде. А если нет, то мы знаем в каких местах что сломалось. Недавно убирал устаревшую функциональность из кода. Всего было задето немногим больше 90 классов и больше тысячи строк. Когда такое делаешь, то только на юнит тесты молишься. Ибо после таких изменений найти ошибки и исправить без юнит тестов это хуже ада.
@goriaev
29 күн бұрын
Об этом говорится в конце. Но говорится типа это небольшая польза)))
@bartbelrigvardo5216
29 күн бұрын
@@goriaev согласен с автором, вначале польза небольшая. Но со временем это становится чуть ли не стержнем, вокруг которого держится проект. Когда приходишь на код, который начинали писать ещё наши деды-индусы, то только юнит тестами и живешь
@goriaev
29 күн бұрын
@@bartbelrigvardo5216 понятно, что для hello world-a тесты не нужны. Но тесты нужны впринципе. Я понял основную идею видео, что тесты нужны только в проектах с большой ценой ошибки. И от них больше оверхеда, а польза небольшая. Нашли баг - поправили. С этим я не согласен
Это какой-то бред сивой кобылы. "Добавляю функционал не порчу существующий". --- если ты такой гений, то тебе не нужны тесты, тебе не нужны видео на ютьюб, тебе нобелевку пора давать. Когда добавляются функции, когда делается рефакторинг, когда появляются новые входные данные, как убедиться, что ничего не ломается? Юнит-тесты дают, хоть какую-то гарантию.
Рупор всем дали, а голову всем не дали
@user-rp3fc4dh7c
28 күн бұрын
Exactly
Зависит от стека технологий и задач. Попробуйте на плюсах низкоуровневые библиотеки под люнух без юнит-тестов пописать. Вопрос даже не в том, когда вы их отладите. Это не в разы дольше, а никогда. Их вообще невозможно без тестов запускать. А писать авто-тесты для UI, да, бессмысленно. Дешевле регресс делать манки тестами по плану тестирования. Уточняйте область, а не категорично обобщайте.
Видео очень крутое, продолжай! Можешь убрать высокие частоты звука? Уши режет
Добавлю: если в компилируемых языках часть работы по тестированию выполняет за вас компилятор, то в интерпретируемых никто кроме вас её не сделает. Поэтому юнит-тесты наше всё. С них надо начинать. Сначала пишете тест. Запускаете его. Он падает. Затем допиливаете функционал под этот тест, пока тест не перестаеет падать.
@AlexeyProgramming
27 күн бұрын
TDD только для бэкенда подходит где есть чёткая формализация задачи и поведения
@DaddyTorque
27 күн бұрын
@@AlexeyProgramming я не программировал для вэба, но мне кажется, фронтенд можно так написать, чтоб он был в каком-то виде тестируемым.
@AlexeyProgramming
27 күн бұрын
@@DaddyTorque фронт слишком часто меняется и даже в процессе разработки структура на усмотрение программиста, какой смысл начинать с теста где ты опишешь сколько там должно быть кнопок и что они должны делать?
@DaddyTorque
23 күн бұрын
@@AlexeyProgramming например, могут быть какие-то простые требования с точки зрения дизайна (что кнопки и окошки для ввода текстовой информации должны быть выровнены). Можно сделать структуру фронтенда так, что данные о положении и размерах кнопок будут доступны для тестов. Соответственно, можно сделать тест на эргономичность расположения контролов. Можно сделать тест на то, что контролы не исчезают за границами при изменени размеров окна, при изменении ориентации экрана. Что контролы не наезжают друг на друга. Можно сделать тест на то, что ни один обработчик ни одного из контролов не выполняется дольше определённого времени. Возможно, можно как-то сделать какой-то анализатор кода фронтента и натравливать его на исходный код с целью нахождения ошибок. Всё, сказанное выше - мои догадки, т.к. я ни разу не фронтендер. Более того, возможно эти догадки целесообразны для каких-то больших проектов с большой посещаемостью и нецелесообразны для маленьких проектов, которыми пользуются 5 человек.
главная проблема с которой я чаще всего сталкивался - это разработчики с "тестами головного мозга", по-другому и не скажешь, их хлебом не корми, только дай тесты писать ) это может быть бесконечно правильно, вот только менеджменту на это насрать, так как задача должна быть сделана ещё вчера и в рабочем состоянии
Почему вы пишете код с багами? Просто пишите с первого раза без багов и всё
Порой у меня ощущение складывается, что не смотря на то, сколько уже книг написали, сколько роликов про тестирование выложили, всё будет идти по одним и тем же граблям раз за разом. Писать тесты долго и затратно, их часто пишут плохо, их часто просто переписывают из-за ложных срабатываний. Это всё верно, но, это цена которую ты платишь за быстрый отлов регрессии в качестве. Отловить баг в todo листе не составит никаких проблем и без тестов, но стоит тебе взяться за 2-3 годовалый проект, и вся эта мишура про "Нам и без тестов нормального в дебаггере по 2-3 часа сидится" сходит на нет Но честно, я бы и сам не стал прототипировать что-то обкладываясь тестами
Юнит тесты оправданны в случаи разработки большого совта. Если ты работаешь с драйверами, движками и подобным, то юнит тесты - необходимость. Хотя, я согласен, что юнит тесты не нужны для фронта. Я пишу свой яп, и там юнит тесты зачастую спасают. Любое изменение компилятора влачит за собой тонну багов которые нельзя выпускать в прод. Например, у меня один раз сломался логический парсер, он просто не хотел правильно обрабатывать сложные конструкции со скобками and и or. Тогда у меня тесты как раз выручили. P.S. Юнит тесты еще можно использовать для проверки web сервисов. Я обычно их использую для сервисов связанных с бд и подобным.
Как по мне тесты надо писать на сложные юниты, от которых зависит много другого кода и у которых у самих мало зависимостей, для всего остального от юнит тестов больше головной боли чем пользы
Привет! А как в компаниях дела обстоят с тестами, если это к примеру не банк/медицина, а ты джун? Надо ли будет в них углубиться тому, кто без опыта, перед трудоустройством? Поделись пожалуйста :)
@enmaboya
26 күн бұрын
всё обычно: 1) манагерам нужен результаты здесь и сейчас; 2) из-за тестов времени тратится больше, манагерам это не нравится; 3) в лучше случае получится объяснить манагеру, что хоть какие-то тесты нужны, в худшем будешь искать другую работу )
По поводу того, что юниты нужны только в банковском софте, давно пользовались продуктами Яндекса? Баг на баге и багом заправляет. Отвратительно, испортились у них все, абсолютно все продукты. Хреново, что они монополисты в такси и доставке еды.
Советую почитать Хорикова, принципы Юнит-тестирования, одна из книг которая повлияла на меня очень сильно, все советуют ее почитать, но никто будто и не читал. От себя хочу сказать, под понятием юнит тестов многие подразумевают разное, тесты - тема глубокая, не зря существует отдельная профессия, для того чтобы тестировать что-то, и нет, тестировщики не занимаются ерундой - хороший тестировщик это лучший друг разработчика. Лично я полагаюсь сначала на E2E тесты, потом на функциональные, и чем больший скоуп интеграций они затронут - тем лучше. Потом на юниты, юниты не боюсь выпиливать если они слишком связывают руки на рефакторинге, и превращаются в поток моков. Но так-же активно их пишу, особенно если разрабатываю утилиты или вспомогательные методы
@pavelbasmanov2192
29 күн бұрын
А еще, юниты которые взрываются на рефакторинге а не проверяют баги - печалька, это либо проблемы с модульностью и качеством кода, либо подходом
is this such a trick: to say stupid things to make others write more comments? I'm in...
Конструктивно и без хейта, обратная связь: На минуте 1:50 ты говоришь, что: "он не может учитывать всех сценариев, когда он пишет тесты,, юнит тесты для этой функции. " - это заблуждение. Так как должны учитываться абсолютно все исходы функции или метода которого ты проверяешь юнит тестами . Именно для этого и делаются Юнит тесты. Кстати советую тебе углубляться в тему Юнит Тестов. Ключь в названии. А если добавляется новый функционал с новыми исходами, то тогда и его пркрывают юнит тестами.
@vilivermb
27 күн бұрын
В общем случае невозможно учесть все исходы. Например, если функция складывает два числа, то пришлось бы писать тест со всеми комбинациями чисел.
"...Только когда мы пишем софт, который не приемлет никаких ошибок и никаких багов". Нет, друг, для хорошего программиста это не только банковский и медицинский софт. Это любой софт, за который он несёт ответственность. Если программист допустил баг при разработке будильника, врач может проспать важную операцию. Я уже не говорю о практике TDD, когда сначала пишутся тесты, а потом рабочий код. О её пользе написано много статей.
@enmaboya
26 күн бұрын
о вреде и бредовости TDD написано статей не меньше, так что не аргумент
Пирамида тестирования.
В какой проге он рисует?
Хотел поставить дизлайк, так как для меня это филькина грамота и зачем я тут не понял, но ... лайков всего 15. Жаль этого добряка...
@user-rp3fc4dh7c
28 күн бұрын
да, человек старался, диаграммы рисовал, видео записывал... просто он забыл подумать перед этим или опыт небольшой
Что вместо unit-тестов, вазелин?
Открою небольшую тайну: компании не проблема нанять 2х, 3х, 10х разработчиков, чтоб тратить больше времени на написание юнит-тестов. А вот когда один разработчик своей правкой вносит баг, который фиксился уже раз 10 и этот баг задерживает релиз - вот это для менеджера проблема. Т.е. юнит тесты - это про то, чтоб обменять немножечко времени на предсказуемость. Кроме того, юнит тесты - это своего рода документация ваших ожиданий относительно того, как функция будет себя вести. Пока юнит тест не упал - можно считать, что такого поведения от функции никто и не ожидает.
@ntvisigoth
29 күн бұрын
Вот ровно об этом же сегодня написал. Прям развернуто. Очень жаль, что на ютуб есть подобные этому видосу. Ведь они кого-то "научат" и потом к тебе такой вот коллега придет и ты будешь думать, как бы ему исправить подходы (((
@MichaelKondrashin
28 күн бұрын
Я хочу вставить свои пять копеек - нет не "времени". Без юнит тестов разработка завязнет при очередном внесении изменений и никакого выигрыша по времени не получится. Так что на долгой дистанции - сплошной выигрыш
прежде чем выложить видео у автора не прошли валидацию юнит тесты с реальными примерами, но прошли с воздушными func A...B...C
Понятно, мы вам перезвоним
Не надо хейтить парнишу, он просто ещё не писал код в команде и не работал над проектами с периодом поддержки дольше 1 месяца. Когда дорастёт до проектов покрупнее сам всё осознает, покраснеет от позора, и сотрёт это видео 😀
Да когда ж школота перестанет писать обучающие ролики... "программист не может предусмотреть все ситуации. " Может и должен. Прэтому методы и разбиваютс на элементарные части. А потом приходит школота с острым желанием все переделать и которая ничего сама предусмотреть не может и единственная защющита от школоты - это юниттесты.
Отличный видос, спасибо за информацию!
Боже какая чушь.