Я без шуток, мне интересно посмотрет

Это в планах

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

Но в моих тестах я просто мокаю что мне надо и проверяю результат

Код короче и читаемее выходит. 😳

Это как так? Покажи пример

ты сам тест не в тф пишешь разве?

со StateT? 🙂

юзаем StateT[Coeval, S, *] там где необходимы точные снэпшоты мира. руками написали только Parallel.identity

Я сам не использую ТФ, но, если бы использовал, писал бы функциональные тесты в ИО: чем ближе интерпретатор в тесте к реальному интерпретатору, тем лучше фактический ковераж.
Ну и если рассматривать тестируемую систему как black box, то список ее capabilities это в некотором смысле внутренние детали реализации.

> чем ближе интерпретатор в тесте к реальному интерпретатору, тем лучше фактический ковераж.
кен ю елаборейт?

Есть такое понятие в мире тестирования - тестовая пирамида. Вы стараетесь вместо интеграционных тестов писать юнит тесты, вместо юнит тестов гарантировать особенности типами, вместо типов вообще не писать код, если можно его не писать и т.п.

Тесты с IO должны быть, но гонять все тесты через IO - это усложнение себе жизни, создание flaky тестов и т.п.

Утрированный пример: попробуйте писать все тесты для вашего сайта через selenium и браузер. Реально же ваш язык интерпретирует ещё и браузер, а не только IO.

Конечно, если вы не используете TF, то этот уровень легковесных тестов вам не доступен, точно так же как коду на JavaScript не доступна работа с типами.

Но грех не использовать если у вас он есть 😊

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

Спасибо!

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

А мы вообще не пишем юнит тесты на F[_]. Имхо, это пустая трата времени и усложнение будущих рефакторингов. ФП достаточно выразителен, чтобы доверять тому, что ты пишешь, не тестируя всякую ерунду. А вот acceptance тесты реальных эндпоинтов - это тру. Но если надо протестить какую-то логику прям хитрую, то есть смысл её выделить в чистую функцию и её уже тестить.

Бывает что есть логика вместе с F 🤷‍♀️

Coeval - это SyncIO?

Бывает, но зачастую она строится из достаточно проверенных примитивов, которые тестить смысла нет. Ну допустим цепочка EitherT со всякими ensure/semiflatMap/etc - смысла это тестировать мало.