Сначала надо создать хорошую инфраструктуру для тестов :)

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

Альтернативы - жить так или выкинуть все. Не лучше.

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

И ещё. Плохой код даже со 100% тестов останется плохим. Хороший даже без тестов хорош и может меняться. Хотя в целом корреляция сильная

Ну это да. Любой понятный тест помогает

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

Гребаный карго культ какой то

Самое прикольное в подсчётах "ковереджа" это то, что он никак не учитывает что в коде теста может не быть ни одного ассерта вообще и глухие трай/кетч блоки.  То есть он вроде большой, а толку ноль, даже минус один т.к. появляется ложная уверенность в том, что "ну тесты же все проходят"

Ну на месте ковереджа мог быть mutation coverage. Сути моего тезиса не меняет...

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

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

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

Возможно. Но я был бы поаккуратнее с заявлением, что "самый простой и разумный способ внедрять тесты в старый код- писать их на все баги во время правки".

Уговорили, не буду. 🤐

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

А почему вы тикет фичи не используете для этих коммитов?

Иногда используем. Так началось обсуждение с голосования. Нашёл тестер багу в новой фиче, знает как исправить, надо ли ему тут заводить? Вопрос такой был. Я и говорю, что необязательно. Здесь он тоже может сослаться на тикет фичи.

s/тут/тикет/

OK, понял, спасибо! У меня голосование не видно)

На, посмотри