а остальные случаи можно к этому случаю привести

как ты удостоверишься, что все инварианты покрыты: все ошибки обработаны, все краевые случаи в логике и т.п.?

а зачем нам такая функция? это и не функция вовсе, это просто оператор композиции в таком случае

А как насчет чтобы такие функции превратить просто в набор вызовов других функций и не покрывать юнит тестом? У меня такая идея пришла что если все вызываемые функции проюнитесчены то их композиция посути уже тоже проюниттесчена автоматом

ну явно не тестами. Логику надо писать и композировать на чистых функциях/структурах, и если она укладывается в типы, то за тебя проверит компилятор

ну потому что нам нужны такие композиции чтобы ими оперировать

Только если функции чистые.

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

ну так и вынеси эту логику в отдельную функцию и ее проюнитестируй

да даже кстати если и нечистые, мы же за dependency rejection, нас интересует unit test только чистых функций

ее и тестируем. эта логика имеет n зависимостей. предмет дискуссии - найти удобный способ их туда передавать при условии, что ни мейнстримовый DI, ни ООП в целом недоступны в силу каких-то причин

до сих пор такой способ обнаружен не был

Чот тяжело конечно _правильно_ код писать на фп

на ооп писать тоже тяжело. Разница в том, что там люди научились делать вид, что это не так

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

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

больше — возможно. Структурирован лучше — ну хуй знает. Они там до сих пор не могут договориться, как правильно паттерны реализовывать/применять. И большая часть их best practices очень напоминает народную медицину: "Я попробовал это и у меня все прошло. Рекомендую"

проблема в “как с этим всем теперь взлететь”

Без g и h никак: они описывают объективно необходимый и достаточный минимум.

когда-нибудь, конечно же, и фп наберет те же объемы, которые приведут к качественному скачку

совершенно верно. но лететь как-то надо. надо написать тест, не зависящий от конкретной реализации g и р (мы ж абстрагируемся), надо, чтобы пользоваться f было не сложнее, чем обычной функцией

Оно же только мейнстримом становится

ну дело-то не только во времени. надо еще и людей побольше

Так сигнатуры на то и нужны. Пока сами типы достаточно хороши, ты всегда можешь подсунуть фейк. Даже если типы плохи, то можешь, просто некрасиво будет. Я не прав?

прав. но мы обсуждаем конкретно реализацию. теория ок

Я не верю в какой-то Единственно Правильный Способ (ТМ). Чувство меры и ощущение прекрасного тебе в помощь.

мейнстримом оно становится очень давно, с 60х

Ну в плане в области тырпрайз

как конкретно подсунуть?

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

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

inb4 private и “кладите рядом”, но это как раз попытки проэмулировать ооп из изоленты и палок

однако интересно посмотреть на инкапсуляцию в чисто фп стиле, без эфшарповых методов на рекордах

а в моей команде для этого есть взвод фанатиков

зачем они это делают, это конечно вопрос

однако интересно посмотреть на инкапсуляцию в чисто фп стиле, без эфшарповых методов на рекордах

собственно, я наблюдаю это на практике. идеоматический код на хаскеле страдает всеми детскими болячками оопешного кода из 90х