Зачем нужны юнит тесты?

Такое ощущение что чтобы просто были. Очень редко пригождаются.

И пофиг что они зачастую намного сложнее и больше времени занимают чем сам код. Где-то видел аргумент, что если код части меняют, то это удобно. Что удобно, ещё юнит тесты менять вместе с хтим кодом каждый раз?) Тем более от ошибок они вообще ни разу не спасают, ибо если не предусмотрел что-то когда писал код - не учтешь это и в тесте. Радует что у нас хотя бы низкий % покрытия тестами в проекте.

А какой а среднем этот процент, интересно?

Видос

Тень228 сказал(а):↑

Такое ощущение что чтобы просто были. Очень редко пригождаются.

И пофиг что они зачастую намного сложнее и больше времени занимают чем сам код. Где-то видел аргумент, что если код части меняют, то это удобно. Что удобно, ещё юнит тесты менять вместе с хтим кодом каждый раз?) Тем более от ошибок они вообще ни разу не спасают, ибо если не предусмотрел что-то когда писал код - не учтешь это и в тесте. Радует что у нас хотя бы низкий % покрытия тестами в проекте.

А какой а среднем этот процент, интересно?

Нажмите, чтобы раскрыть...

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

Вот ты сделал задачу, запушил, она прошла все инстанции (код ревью, qa и т.д.), после чего с релизом попадает в dev ветку. И потом оказалось, что клиент делает всё то, что привык делать, и у него это не работает. Естественно клиент недоволен, но пока он свяжется со службой поддержки, пока та передаст тикет для ПМа, пока они его сформируют и отправят далее, где его просмотрят на корректность составления задачи, могут ли такое сделать (я понимаю, что если это баг, то его вне очереди по приоритету пускают, но процесс всё равно не медленный), пока за него возьмётся программист, пока снова все эти пути пройдут и так далее, может повториться неоднократно

 

Ну и грамотно составленные юнит тесты позволяют отследить все проблемные места (ключевое слово грамотно)

Александр сказал(а):↑

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

Вот ты сделал задачу, запушил, она прошла все инстанции (код ревью, qa и т.д.), после чего с релизом попадает в dev ветку. И потом оказалось, что клиент делает всё то, что привык делать, и у него это не работает. Естественно клиент недоволен, но пока он свяжется со службой поддержки, пока та передаст тикет для ПМа, пока они его сформируют и отправят далее, где его просмотрят на корректность составления задачи, могут ли такое сделать (я понимаю, что если это баг, то его вне очереди по приоритету пускают, но процесс всё равно не медленный), пока за него возьмётся программист, пока снова все эти пути пройдут и так далее, может повториться неоднократно

 

Ну и грамотно составленные юнит тесты позволяют отследить все проблемные места (ключевое слово грамотно)

Нажмите, чтобы раскрыть...

"х**к х**к и в продакшн"

 

Тестирование понимаешь ли. Может еще регресс основного функционала проводить?

Давай ваще без тестов программировать

Пёс Да Лис сказал(а):↑

Давай ваще без тестов программировать

Нажмите, чтобы раскрыть...

В маленьких конторах о тестах вообще не слышали))

Gissh сказал(а):↑

"х**к х**к и в продакшн"

 

Тестирование понимаешь ли. Может еще регресс основного функционала проводить?

Нажмите, чтобы раскрыть...

Работаю на аутсорсе в крупном российском банке

Регресс каждые 2 недели 

Gissh сказал(а):↑

"х**к х**к и в продакшн"

 

Тестирование понимаешь ли. Может еще регресс основного функционала проводить?

Нажмите, чтобы раскрыть...

Программисты регресс разве делают?

linkinpros сказал(а):↑

Работаю на аутсорсе в крупном российском банке

Регресс каждые 2 недели 

Нажмите, чтобы раскрыть...

У нас регресс при каждом релизе идет. Если нет изменений, то зачем регресс?

y6ejushe сказал(а):↑

Программисты регресс разве делают?

Нажмите, чтобы раскрыть...

нет, но иногда тестирование просит помочь подключится, данные там залить какие нибудь или по функционалу уточнения

Так может ты не умеешь писать тесты, если они не вылавливают ошибки?)))

Че? Юнит-тесты не надо менять при изменении логики, только при изменении интерфейса. Юнит-тест просто проверят ограничения, которые накладываются на возвращаемое функцией значение, поэтому он пишется раньше тела самой функции. Такое тестирование очень простое и быстрое, им может (и в идеале должен) заниматься сам программист для предотвращения ошибок в реализации.

Для меня это тоже большая загадка, все кричат об этих unit тестах, а применять то их где? Большая часть кода всегда тривиальная и писать тесты на 2 + 2 это тупая трата времени. А когда код не тривиален, то зачастую и входные данные там такие какие фиг вручную подберешь вообще, а зачастую вообще нереально написать тест или для того чтобы его написать надо затратить на порядок больше усилий нежели на сам код. 

Эти unit тесты так называемые, годятся лишь для процедур где простые входные данные, простые выходные. А когда процедура меняет состояние вне этой самой процедуры то тут начинается посос. И самое ужасное, что этот самый код который меняет состояния и является самым опасным с точки зрения багов. Оторванную от реальности процедуру и так очень легко отдебажить и понять что проблема именно в ней.

 

Еще одна фишка от эффективных манагеров, лишь бы прогеров ненужным говном загрузить, на уровне этих отсчетов бесполезных где надо писать чем занимался какие задачи решил и так далее. На бумаге хорошо - на деле говно, как обычно.

haHAA сказал(а):↑

Видос

Нажмите, чтобы раскрыть...

ток хотел кинуть

Pudgewerksaw сказал(а):↑

Для меня это тоже большая загадка, все кричат об этих unit тестах, а применять то их где? Большая часть кода всегда тривиальная и писать тесты на 2 + 2 это тупая трата времени. А когда код не тривиален, то зачастую и входные данные там такие какие фиг вручную подберешь вообще, а зачастую вообще нереально написать тест или для того чтобы его написать надо затратить на порядок больше усилий нежели на сам код. 

Эти unit тесты так называемые, годятся лишь для процедур где простые входные данные, простые выходные. А когда процедура меняет состояние вне этой самой процедуры то тут начинается посос. И самое ужасное, что этот самый код который меняет состояния и является самым опасным с точки зрения багов. Оторванную от реальности процедуру и так очень легко отдебажить и понять что проблема именно в ней.

 

Еще одна фишка от эффективных манагеров, лишь бы прогеров ненужным говном загрузить, на уровне этих отсчетов бесполезных где надо писать чем занимался какие задачи решил и так далее. На бумаге хорошо - на деле говно, как обычно.

Нажмите, чтобы раскрыть...

Так ты и не должен делать тесты для тривиальных задач, ты чё поехавший

Александр сказал(а):↑

Так ты и не должен делать тесты для тривиальных задач, ты чё поехавший

Нажмите, чтобы раскрыть...

А не для тривиальной задачи написать юнит тест будет невероятно сложно.

Pudgewerksaw сказал(а):↑

А не для тривиальной задачи написать юнит тест будет невероятно сложно.

Нажмите, чтобы раскрыть...

Так я и не писал нигде, что это просто

Они обязательны везде, где нужно проверить нестандартный кейс или большой объём входных данных, которые вручную ты будешь проверять дольше

Александр сказал(а):↑

Так я и не писал нигде, что это просто

Они обязательны везде, где нужно проверить нестандартный кейс или большой объём входных данных, которые вручную ты будешь проверять дольше

Нажмите, чтобы раскрыть...

Вот с большими данными тут возникает главная проблема, чтобы проверить большое количество случаев, нужно эти проверочные данные где-то достать, либо через уже существующую программу которая точно работает (тогда вопрос, зачем ты изобретаешь велосипед), либо на основе уже откуда то-полученных данных (допустим данных из прошлого, если ты допустим пишешь прогнозирующую программу). То есть очень часто возникает такая проблема что проверочные данные тупо негде достать, тебе надо сначала написать программу чтобы получить хоть какие-то данные, тут то и tdd ломается. И самое ужасное что это и есть большинство нетривиальных кейсов. И тут уже и получается что тесты нужны только для того чтобы в будущем программа не сломалась, ну и тут смысл небольшой, так как рабочий код редко меняют, а если и меняют то зачастую он сложный и забывается, что в большинстве случаев приводит к переписывается с нуля.

И это только чистые процедуры с входом и выходом. А если процедура меняет внешнее состояние, то тут все, тесты умывают руки. И причем эти грязные процедуры это взаимодействие с ui/os/io/server/движком.. то есть то чем и занимаются по сути программисты если выкинуть все абстракции, да и даже методы класса можно считать грязными процедурами.

Тень228 сказал(а):↑

И пофиг что они зачастую намного сложнее и больше времени занимают чем сам код.

Нажмите, чтобы раскрыть...

Что за бред вообще, если ты пишешь такой код что его тяжело тестировать, то проблема в тебе скорее всего

Pudgewerksaw сказал(а):↑

Для меня это тоже большая загадка, все кричат об этих unit тестах, а применять то их где?

Нажмите, чтобы раскрыть...

Ну например пишешь ты слой бд, интерфейсов никаких у тебя нет, как проверить твои сейвы апдейты и делиты?

Тут ты и пишешь юнит тест

Александр сказал(а):↑

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

Вот ты сделал задачу, запушил, она прошла все инстанции (код ревью, qa и т.д.), после чего с релизом попадает в dev ветку. И потом оказалось, что клиент делает всё то, что привык делать, и у него это не работает. Естественно клиент недоволен, но пока он свяжется со службой поддержки, пока та передаст тикет для ПМа, пока они его сформируют и отправят далее, где его просмотрят на корректность составления задачи, могут ли такое сделать (я понимаю, что если это баг, то его вне очереди по приоритету пускают, но процесс всё равно не медленный), пока за него возьмётся программист, пока снова все эти пути пройдут и так далее, может повториться неоднократно

 

Ну и грамотно составленные юнит тесты позволяют отследить все проблемные места (ключевое слово грамотно)

Нажмите, чтобы раскрыть...

И зачем ты меня заставил читать этот высер ни о чем? Ну баг и баг. Как это связано с сабжем? Если баг прошел qa, то твои сраные юнит тесты уж точно не помогут его предусмотреть.

IKYouRBad сказал(а):↑

Так может ты не умеешь писать тесты, если они не вылавливают ошибки?)))

Нажмите, чтобы раскрыть...

А может пошел на

rot1t сказал(а):↑

Че? Юнит-тесты не надо менять при изменении логики, только при изменении интерфейса. Юнит-тест просто проверят ограничения, которые накладываются на возвращаемое функцией значение, поэтому он пишется раньше тела самой функции. Такое тестирование очень простое и быстрое, им может (и в идеале должен) заниматься сам программист для предотвращения ошибок в реализации.

Нажмите, чтобы раскрыть...

И че часто приходится менять логику вообще не меняя входные-выходные данные? Че-то не знаю такого. Обычно надо что-то как-раз таки добавить. Да и при изменении логики тоже могут добавиться новые моки и пр.

pochemyzamenya сказал(а):↑

Что за бред вообще, если ты пишешь такой код что его тяжело тестировать, то проблема в тебе скорее всего

Ну например пишешь ты слой бд, интерфейсов никаких у тебя нет, как проверить твои сейвы апдейты и делиты?

Тут ты и пишешь юнит тест

Нажмите, чтобы раскрыть...

Я не знаю как там в вашем html с тестами, а в го досточно туго и приходится вручную писать все моки, что уже немало времени занимает как минимум. 

Pudgewerksaw сказал(а):↑

Вот с большими данными тут возникает главная проблема, чтобы проверить большое количество случаев, нужно эти проверочные данные где-то достать, либо через уже существующую программу которая точно работает (тогда вопрос, зачем ты изобретаешь велосипед), либо на основе уже откуда то-полученных данных (допустим данных из прошлого, если ты допустим пишешь прогнозирующую программу). То есть очень часто возникает такая проблема что проверочные данные тупо негде достать, тебе надо сначала написать программу чтобы получить хоть какие-то данные, тут то и tdd ломается. И самое ужасное что это и есть большинство нетривиальных кейсов. И тут уже и получается что тесты нужны только для того чтобы в будущем программа не сломалась, ну и тут смысл небольшой, так как рабочий код редко меняют, а если и меняют то зачастую он сложный и забывается, что в большинстве случаев приводит к переписывается с нуля.

И это только чистые процедуры с входом и выходом. А если процедура меняет внешнее состояние, то тут все, тесты умывают руки. И причем эти грязные процедуры это взаимодействие с ui/os/io/server/движком.. то есть то чем и занимаются по сути программисты если выкинуть все абстракции, да и даже методы класса можно считать грязными процедурами.

Нажмите, чтобы раскрыть...

Тестами проверяешь результат, а не то, как работает метод. Если метод/процедура меняет внешнее состояние, то ты пишешь для них новые тесты, всё логично. Часто ли у тебя бывает такое, что метод начинает возвращать не то, что от него ожидается? Предсказуемый ответ - нет. Конкретно кейс, при котором у тебя есть тесты для этого метода, где ты ожидаешь, что этот метод всегда будет возвращать например объект, или вдруг метод неожиданно вернул исключение. Вот мы отловили исключение, увидели, что потребовалось для того, чтобы это воспроизвести, и исправили. Запустили повторно - тест прошёл на ура. В данном случае мы запустили 

 

В принципе всё, для чего нужны тесты. Метод всегда должен возвращать одинаковое состояние (содержимое не в счёт) и он не должен из объекта/значения превратиться в другое состояние/тип только потому, что мы в новой задаче изменили логику или поведение какого-то момента внутри задачи, который затронул второй и так по цепочке. Я хз, как это проще объяснить

 

Тень228 сказал(а):↑

И заяем ты меня заставил читать этот высер ни о чем? Ну баг и баг. Как это связано с сабжем? Если баг прошел qa, то твои сраные юнит тесты уж точно не помогут его предусмотреть.

Нажмите, чтобы раскрыть...

Пушо ты лох глупый несамостоятельный и вообще несообразительный

Баг произошёл из-за чего? Потому что программист ошибся, и при определённом кейсе метод вернул не то, что от него ожидали. Всё просто, а ты просто глупый лох (напоминаю)

Александр сказал(а):↑

Тестами проверяешь результат, а не то, как работает метод. Если метод/процедура меняет внешнее состояние, то ты пишешь для них новые тесты, всё логично. Часто ли у тебя бывает такое, что метод начинает возвращать не то, что от него ожидается? Предсказуемый ответ - нет. Конкретно кейс, при котором у тебя есть тесты для этого метода, где ты ожидаешь, что этот метод всегда будет возвращать например объект, или вдруг метод неожиданно вернул исключение. Вот мы отловили исключение, увидели, что потребовалось для того, чтобы это воспроизвести, и исправили. Запустили повторно - тест прошёл на ура. В данном случае мы запустили 

 

В принципе всё, для чего нужны тесты. Метод всегда должен возвращать одинаковое состояние (содержимое не в счёт) и он не должен из объекта/значения превратиться в другое состояние/тип только потому, что мы в новой задаче изменили логику или поведение какого-то момента внутри задачи, который затронул второй и так по цепочке. Я хз, как это проще объяснить

 

Пушо ты лох глупый несамостоятельный и вообще несообразительный

Баг произошёл из-за чего? Потому что программист ошибся, и при определённом кейсе метод вернул не то, что от него ожидали. Всё просто, а ты просто глупый лох (напоминаю)

Нажмите, чтобы раскрыть...

А теперь напряги немного свой 50iq котелок и подумай, а если программист такой кейс не предусмотрел, откуда он его высрет для юнит теста.

Тень228 сказал(а):↑

А теперь напряги немного свой 50iq котелок и подумай, а если программист такой кейс не предусмотрел, откуда он его высрет для юнит теста.

Нажмите, чтобы раскрыть...

А теперь сделай то же самое и подумай, какие могут быть кейсы в принципе

Ну более маштабно, гораздо маштабнее, чем то, на что способна твоя черепушка

 

Из элементарного - у тебя есть заказ, в котором есть груз, в котором есть рейсы, которые ожидают завершения, консолидации, хендлеры и так до бесконечности. К вам в компанию пришёл новый программист, который увидел какую-то логику, отвечающую за распределение грузов по консолидациям для дальнейшей отправки. На код ревью никто не заметил подвоха, qa даже и не вспомнили про кейс, под который заточена твоя логика, а тесты выдали СТОЯТЬ В СМЫСЛЕ А ЧЁ ТЫ МНЕ ВЕРНУЛ ВАЩЕ? Вот тут задачка возвращается программисту, который такой а да точно, и исправляет, пока результат метода не будет удовлетворять тест, который был написан ещё до его прихода. Всё просто

Александр сказал(а):↑

А теперь сделай то же самое и подумай, какие могут быть кейсы в принципе

Ну более маштабно, гораздо маштабнее, чем то, на что способна твоя черепушка

 

Из элементарного - у тебя есть заказ, в котором есть груз, в котором есть рейсы, которые ожидают завершения, консолидации, хендлеры и так до бесконечности. К вам в компанию пришёл новый программист, который увидел какую-то логику, отвечающую за распределение грузов по консолидациям для дальнейшей отправки. На код ревью никто не заметил подвоха, qa даже и не вспомнили про кейс, под который заточена твоя логика, а тесты выдали СТОЯТЬ В СМЫСЛЕ А ЧЁ ТЫ МНЕ ВЕРНУЛ ВАЩЕ? Вот тут задачка возвращается программисту, который такой а да точно, и исправляет, пока результат метода не будет удовлетворять тест, который был написан ещё до его прихода. Всё просто

Нажмите, чтобы раскрыть...

А, ну то есть мы вернулись к этому. Ну тогда вопрос вожникакт: а может стоит не тратить 80% рабочего времени на сраные тесты, а сделать код получше чтобы его не было необходимости переписывать? Или вы там просто ауты и по фану одно и то же переписываете без изменения входных/выходных данных друг за другом, типа имитация бурной деятельности (т.к. при их изменении сраные тесты придется менять)

Тень228 сказал(а):↑

Я не знаю как там в вашем html с тестами, а в го досточно туго и приходится вручную писать все моки, что уже немало времени занимает как минимум. 

Нажмите, чтобы раскрыть...

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

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

pochemyzamenya сказал(а):↑

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

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

Нажмите, чтобы раскрыть...

Господи че ты высираешь. Я тебе написал как есть. Чтобы протестировать сервисную функцию в 3 строчки которая допустим получает слайс из бд, фильтрует его и отдает дальше, у тебя пара часов уйдет тупо чтобы замокать бд и несколько входных слайсов вручную гаписать, не ********* тут лучше а.