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

а раз есть изменение - то нужны и тесты на соответствующий модуль, в который вносятся изменения

Согласен. У нас практикуется попинывание регулярно.  Ведём дискуссии о целесообразности guerilla unit тестинга.

у нас тоже, и я хочу сказать, что это имеет полезный эффект

мы называем это innovation days, официально постулируется, что это время можно потратить на игрища с какими-то новыми технологиями, которые может подойдут нашему проекту, а может нет

Ну вот об этом и дискуссия. В тупую - почему в тупую. Тесты должны были написаны ранее. Ну не написали. Ещё не конец света. Почему дописывание - тупо? По мне - обыкновенный технический долг, у кого-то такого больше,  у кого-то меньше - совсем без долга вряд ли команды бывают. Ну кроме Нетфликса и Омского Мясокомбинат (с Васей).

Это хорошо

я не верю в полезность тестов после релиза

Вопрос религиозный)

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

просто пойти и написать тест - увеличение времени билда в пустую, имхо

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

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

Есть свои тонкости. Например оценки. Разрабы педантично описывают что для новой задачи надо сделать. Поменять тут код, добавить конфигурации, написать 2 юнит-теста, протестировать.  Нормально, берём в спринт.

А тут еще внезапно абсолютно неоцениваемые "написать 500 тестов на остальной код модуля и прорефакторить по необходимости". Да ну его к лешему, думает разраб - и мне сложно его упрекнуть.

степень покрытия в коде расчет очень быстро. постоянно трогается старый код => на него появляются тесты. пускай и не все инварианты, но это лучше, чем вообще без покрытия

сгоревшие сторипоинты не KPI

превысил и превысил, значит были причины

Конкретно у нас - другая боль. Ладно бы превысил, просто задачу в 3 поинта (велосити 25) делал три спринта. И это без этих юнит-тестов. А теперь давайте добавим юнит-тесты...

о боже

ну короче классическое "делать хорошо - слишком дорого для нас"