Продвигаем написание юнит тестов, адекватное описание требований. Прогресс медленный, но есть

адекватное это какое?

Ну это для души)

достойная смена растет

У нас аналитика нет, потому мы на митингах обсуждаем с продактами как много времени уходит у нас на анализ их требований и что они со своей стороны могут делать, чтобы упростить этот процесс

Адекватное - с рассмотрением всех флоу

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

Но этот аналитик бывший директор криптобанка. Туго там идет:(

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

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

пока по чучуть потюкиваю обе стороны

Вопрос.
Существует метод, который принимает x и содержит одну строку return x == 1 ǁ  x == 2 ǁ ...

На такую штуку надо писать юниты?

Прост мне разрабы сказали, что и так видно значения. Че их проверять

Юниты пишутся на поведение функции, а не на очевидность её текущей имплементации.

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

а в каком тогда случае можно говорить об избыточности юнитов? или такого не бывает?

А приведи настоящий код метода.

это и есть настоящий код в одну строку там порядка 12 значений проверяется

я в проекте наткнулся седня

следующий этап - писать руткоз в тикет. Никто не хочет это делать

не, не дойдем до этого, если я пушить не буду, а я не буду)