P
monix.eval.CoevalДовольно тоже мощный эффект 😐
Size: a a a
2021 March 09
EK
А мы вообще не пишем юнит тесты на F[_]. Имхо, это пустая трата времени и усложнение будущих рефакторингов. ФП достаточно выразителен, чтобы доверять тому, что ты пишешь, не тестируя всякую ерунду. А вот acceptance тесты реальных эндпоинтов - это тру. Но если надо протестить какую-то логику прям хитрую, то есть смысл её выделить в чистую функцию и её уже тестить.
плюсую
P
Бывает, но зачастую она строится из достаточно проверенных примитивов, которые тестить смысла нет. Ну допустим цепочка EitherT со всякими ensure/semiflatMap/etc - смысла это тестировать мало.
Примтивы примитивами, но бывает хочется проверить что-то вроде "взял данные из базы - изменил - записал", порядок действий, всё такое.
AS
Python
Примтивы примитивами, но бывает хочется проверить что-то вроде "взял данные из базы - изменил - записал", порядок действий, всё такое.
Надо понять, почему "хочется". Что стоит за этим хотением.
AS
Часто вижу такого рода тесты, утрированно 😁
case class Genius(foo: String)
Genius("foo").foo should be ("foo")
AS
И такого гэ тысячи строк в репе у людей может быть 🤷♂️
EK
Часто вижу такого рода тесты, утрированно 😁
case class Genius(foo: String)
Genius("foo").foo should be ("foo")
Это фанаты Айн Ренд тестируют что А=А
P
Надо понять, почему "хочется". Что стоит за этим хотением.
Двойная запись, как в бухгалтерии. Один раз написал, второй раз, упрощённо, проверил что работает. Ну или, наоборот, для фанатов TDD.
P
Часто вижу такого рода тесты, утрированно 😁
case class Genius(foo: String)
Genius("foo").foo should be ("foo")
Я не про такие тесты. Такие не нужны, конечно.
D
А мы вообще не пишем юнит тесты на F[_]. Имхо, это пустая трата времени и усложнение будущих рефакторингов. ФП достаточно выразителен, чтобы доверять тому, что ты пишешь, не тестируя всякую ерунду. А вот acceptance тесты реальных эндпоинтов - это тру. Но если надо протестить какую-то логику прям хитрую, то есть смысл её выделить в чистую функцию и её уже тестить.
мы так и делаем тестируем функции
A => F[Unit]ΛВ
Скаланы, а как вы проверяете то, что запущенные через fs2-шные par-методы процессы ещё живые?
ΛВ
Условно задача такая — сделать хелсчек, который проверит, что n файберов, читающих из шины, живые и их ровно n штук
EK
Скаланы, а как вы проверяете то, что запущенные через fs2-шные par-методы процессы ещё живые?
А если не живые, то что?
Oℕ
Скаланы, а как вы проверяете то, что запущенные через fs2-шные par-методы процессы ещё живые?
Vector[(Daemon[F, A], Ref[(Instant, Info)])]
ΛВ
А если не живые, то что?
Ну например самое простое — вернуть 5хх и куб рестартанет сервис
Oℕ
непонятно, зачем специально проверять статус запущенного через par
Oℕ
если какой-то процесс сломается, весь par сломается
ΛВ
Мсье разбирается в жрпс
ΛВ
если какой-то процесс сломается, весь par сломается
Об этом я кстати не подумал, когда не я писал этот код
D
эм, и зачем?