@Tagir_Valeev

А стримы типа:

a.stream()
.filter(FilterClass::longMethodWithbunchOfIfs)
.map(MapClass::evenMoreLogicHere)
.collect(...)

Это нормально или зло?

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

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

Ну без стримов, по дедовски, циклы, приватные методы и тд

Ну допустим они разбиты

А чем такая альтернатива лучше?

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

ну, выше с одним фильтром и мапом - это ж не "сложные правила обработки", не?

Так же, как и аналогичную конструкцию с циклом, что не так?

Ну может быть я стримы тестировать не умею. Неочевидно, когда любой тест даёт 100% покрытия понимать, что пропущено.

>Инстинктивно не доверяю конструкции стрима, если
Звучит, как проблема не с кодом, а с мышлением, no offense

для удобства тестирования лучше ссылки на методы объекта юзать

Так стримы не надо тестировать, их тестируют разработчики JVM. Надо поведение программы тестировать.
А если есть метод, принимающий, допустим, коллекцию, над элементами которой проводятся операции или через стрим, или через цикл, то тестироваться он будет совершенно одинаково, потому что интерфейс метода ни хрена не меняется от того, стрим там или foreach-loop внутри.

Может быть. Поэтому и хочу понять, что не так - может недоверие пропадёт.

Эээ. Юнитами ? С различными корнер-кейсами? Чем принципиально тестирование метода со стримами отличается от тестирования метода без стримов?

так-то можно понапихать логику в

for ( <тут дофига всего>

и сказать что говно ваши циклы. неочевидно все и нетестабельно

Ну не сами стримы. В принципе я представляю так: стрим преобразует множество А во множество В. И в принципе у стрима частенько бывает как минимум несколько различных результатов трансформации. Тестировщицким языком - входные данные можно разбить на классы эквивалентности, где для каждого класса есть своя "особенность" при трансформации. Или с позиции написания тестов - "для каждого из классов эквивалентности нужен отдельный тест".

В мире без стримов, мы выбираем представителей, пишем по 1 тесту на каждого, и смотрим на покрытие. Если остались непокрытые места - значит что-то не учли. Если избыточное покрытие - возможно код можно оптимизировать. В общем какие-то есть метрики и признаки.

А в стриме - любой один тест покрывает 100% кода. И как искать пропущенные ветви?

Почему нет? Нормально

Не очень понятно, как стримы влияют на покрытие вашего кода

А как вы ищете пропущенные ветви в методе, аналогично тому, что выше, где будет

for (Element element: collection) {
if (longMethodWithbunchOfIfs(element)) { addToNewList(evenMoreLogicHere(element)) } 
}

? Наличие-отсутствие стрима само по себе на ветвление кода не влияет ровно никак.