Size: a a a

JPoint, Java-конференция

2019 January 29

ПФ

Паша Финкельштейн in JPoint, Java-конференция
Alexey Tomin
Самый простой и разумный способ внедрять тесты в старый код- писать их на все баги во время правки.
Сначала надо создать хорошую инфраструктуру для тестов :)
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Alexey Tomin
Самый простой и разумный способ внедрять тесты в старый код- писать их на все баги во время правки.
ИМХО - ненависть, боль и тщета: писать юнит-тесты с каждой багой на код, который под юнит тестирование не приспособлен никак (тот самый старый код). Долбаная солянка из моков на моках, которая тестит непонятно что - вангую что когда ковередж достигнет критической массы, это говно будет фолс-позитивить на каждый oneliner. Ненависть вобщем.
источник

AT

Alexey Tomin in JPoint, Java-конференция
Альтернативы - жить так или выкинуть все. Не лучше.
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Alexey Tomin
Альтернативы - жить так или выкинуть все. Не лучше.
Альтернатива ИМХО - писать более высокоуровневые тесты. Не на юнит, а на юз-кейс, интеграционные, UI, E2E, короче на что то что более менее приближенно к потребностям бизнеса/цели. Такие хотя бы не потеряют актуальность при рефакторинге старого кода в новый.
источник

AT

Alexey Tomin in JPoint, Java-конференция
И ещё. Плохой код даже со 100% тестов останется плохим. Хороший даже без тестов хорош и может меняться. Хотя в целом корреляция сильная
источник

AT

Alexey Tomin in JPoint, Java-конференция
Ну это да. Любой понятный тест помогает
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Просто у себя щас такое наблюдаю. Ладно код - месиво, инфы никакой, рефакторинг дорогой и никому особо неинтересен (ну всяко бывает - могу еще понять), зато "ааа юнит тесты, тесты нужны конечно, даааа! А давайте еще требованием сделаем - чтоб на каждую багу был юнит тест". Бесит!
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Гребаный карго культ какой то
источник

SB

Sergey Bezrukov in JPoint, Java-конференция
Sergey Kapralov
ИМХО - ненависть, боль и тщета: писать юнит-тесты с каждой багой на код, который под юнит тестирование не приспособлен никак (тот самый старый код). Долбаная солянка из моков на моках, которая тестит непонятно что - вангую что когда ковередж достигнет критической массы, это говно будет фолс-позитивить на каждый oneliner. Ненависть вобщем.
Самое прикольное в подсчётах "ковереджа" это то, что он никак не учитывает что в коде теста может не быть ни одного ассерта вообще и глухие трай/кетч блоки.  То есть он вроде большой, а толку ноль, даже минус один т.к. появляется ложная уверенность в том, что "ну тесты же все проходят"
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Sergey Bezrukov
Самое прикольное в подсчётах "ковереджа" это то, что он никак не учитывает что в коде теста может не быть ни одного ассерта вообще и глухие трай/кетч блоки.  То есть он вроде большой, а толку ноль, даже минус один т.к. появляется ложная уверенность в том, что "ну тесты же все проходят"
Ну на месте ковереджа мог быть mutation coverage. Сути моего тезиса не меняет...
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Alexey Tomin
Альтернативы - жить так или выкинуть все. Не лучше.
И кстати альтернатива "жить так" лучше чем альтернатива "жить как раньше + юнит тесты". Юнит тесты на старом коде будут жить ровно до момента пока не приспичит этот старый код отрефакторить. А значит усилия по написанию юнит тестов на старом коде - это усилия направленные на фиксацию легаси.

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

AT

Alexey Tomin in JPoint, Java-конференция
Случаи бывают разные. Последнее время код все больше попадается такой, что тесты можно добавить в сложные места
источник

SK

Sergey Kapralov in JPoint, Java-конференция
Alexey Tomin
Случаи бывают разные. Последнее время код все больше попадается такой, что тесты можно добавить в сложные места
Возможно. Но я был бы поаккуратнее с заявлением, что "самый простой и разумный способ внедрять тесты в старый код- писать их на все баги во время правки".
источник

AT

Alexey Tomin in JPoint, Java-конференция
Sergey Kapralov
Возможно. Но я был бы поаккуратнее с заявлением, что "самый простой и разумный способ внедрять тесты в старый код- писать их на все баги во время правки".
Уговорили, не буду. 🤐
источник
2019 January 30

ЕТ

Евгений Трифонов in JPoint, Java-конференция
Опубликовали топ-10 докладов прошлогоднего новосибирского JBreak — и так получилось, что целый ряд спикеров оттуда будет в апреле на JPoint (с новыми темами). Так что можно смотреть и морально готовиться к новой встрече с ними! https://habr.com/ru/company/jugru/blog/438098/
источник
2019 January 31

A@

Andrey @zarandr 🇷🇺 in JPoint, Java-конференция
Tagir
Зачем в релиз-нотес писать "исправлено исключение в новой фиче, которую вы сломанной никогда не видели, потому что раньше её не было"?
А почему вы тикет фичи не используете для этих коммитов?
источник

T

Tagir in JPoint, Java-конференция
Andrey @zarandr 🇷🇺
А почему вы тикет фичи не используете для этих коммитов?
Иногда используем. Так началось обсуждение с голосования. Нашёл тестер багу в новой фиче, знает как исправить, надо ли ему тут заводить? Вопрос такой был. Я и говорю, что необязательно. Здесь он тоже может сослаться на тикет фичи.
источник

T

Tagir in JPoint, Java-конференция
s/тут/тикет/
источник

A@

Andrey @zarandr 🇷🇺 in JPoint, Java-конференция
Tagir
Иногда используем. Так началось обсуждение с голосования. Нашёл тестер багу в новой фиче, знает как исправить, надо ли ему тут заводить? Вопрос такой был. Я и говорю, что необязательно. Здесь он тоже может сослаться на тикет фичи.
OK, понял, спасибо! У меня голосование не видно)
источник

T

Tagir in JPoint, Java-конференция
Andrey @zarandr 🇷🇺
OK, понял, спасибо! У меня голосование не видно)
На, посмотри
источник