https://hackage.haskell.org/package/cabal-doctest: this library is obsolete.

у меня не взлетел вызов cabal doctest

За 30 минут выделенные на переход я не добился результата

практика — критерий истины

Безотносительно моков - ты можешь брать любой кусок стрима и тестировать его изолировано.

Например, ты можешь взять each (fixed-stream) & effectfulStream & checkEffect и проверять каждый стрим в отдельности, что ты и должен делать в юнит тестах.

mock-и если нужны делаются через HandlePattern или MonadX, тут ситуация ничем не отличается от твоей, более того, никто не запрещает тебе сделать Stream (Of Message) AppL () и встроить стримы в твой фреймворк.

> неподдерживаемый, лапшеобразный, разнообразный и никоим образом не тестируемый.

Это субьективно, у меня такое же ощущение было от чтения кода Hydra и Node, что тоже субъективно.

Но я поверю, что со стримами можно написать неподдерживаемый код.

> Нет никакого единого дизайна, нет гайдлайнов, да и сложно их представить. В том числе по тестированию.

Почему? В чем проблема иметь гайдлайны?

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

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

перепроверил на cabal-install с чистым кэшом. Cabal теперь не собирается для comonad, например. но cabal-doctest всё ещё тянет. лёгкая зависимость, но всё ещё лишняя

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

я не распрсил твою реплику, но выше ты меня убедил в том, что cabal-doctest (через custom setup) можно пользоваться

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

у меня в зависимостях просто doctest и нет кастом сетапа

в корне тестов есть такой комент:

-- Taken from https://github.com/kowainik/membrain/blob/master/test/Doctest.hs

))

Но у тебя с кабалом не работает?

не работает)

Ну а ты пишешь гайдлайны, скажем, на трансформацию списков в бесточечном стиле? Нет, не пишешь, потому что это низкоуровневый код, и неважно, как он написан. Он решает малые задачи, и пусть кодеры кодят как хотят. Стримы чуть более высокоуровневые, чем списки, но не то чтобы очень. Решение бизнесовых задач на сырых стримах выглядит как применение не того уровня абстракции. Я уже приводил аргумент, что если понадобится SQL подсистема, то ты пойдешь и захачишь ее туда как-нибудь. Не задизайнишь, чтобы это было единообразно, а захачишь. А другая команда захачит совершенно по-своему. То же самое можно сказать про IO в целом. Разработчикам нельзя давать такую свободу, они обязательно начнут ею злоупотреблять. И задачи должны решаться тем уровнем абстракции, который им подходит. Стримы в таком сыром, raw виде - это хачение по месту. Даже FRP был бы более высокоуровневым подходом. Нет смысла делать гайдлайны для низкого уровня, если можно сделать высокоуровневый подход в первую очередь. Это даст больше, чем гайдлайны. Даже сам этот совет - решать задачи соответствующим уровнем абстрацъкции - уже са  по себе гайдлайн.

> решение бизнесовых задач на сырых стримах

мне кажется или никто этого не предлагал?

Не кажется

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