Dependency Rejection and TDD without Mocks. Антон Молдован

[@megasuperlexa2]

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

[@bonumsignum7017]

Фри монады.

[@dmitrii_filippov]

То же интересно, как можно применять идеи из доклада для таких задач. @megasuperlexa2 удалось что-то узнать в этом направлении?

[@ОлегБожок-ф6и]

fuzzy testing думаю в этом случае подойдет

[@АнимусАнанимус]

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

[@bonumsignum7017]

@@АнимусАнанимус Ты не делаешь сайдеффекты, ты их описываешь, а интерпретатор фри монады их уже выполняет.

[@mikhailkalinin6484]

Очень сложно слушать речь докладчика, когда идёт русский язык с множеством вставок английских слов: "мес", "артикл", "реджектить", "миксить" итд

[@asbestoable]

согласен. слушать не возможно. надеюсь за эти 4 года спикер пересмотрел свои взгляды на лексикон при выступлениях

[@ДанилЛозенко-р2с]

Очень режет слух. Или уже выступай на английском или на русском но не надо слонять англ слова.

[@АртемАстапов-ц3м]

Все плохо, вот вам пример. А как правильно мы вам не покажем, сами думайте.

[@TedFanat]

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

[@RusRes]

Поздравляю авторов термина Dependency rejection и его адептов с переизобретением доменного слоя чистой архитектуры. Так держать, ещё несколько лет, и вы переизобретёте bounded contexts и вообще DDD. Догнать и перегнать ООП

[@IgorPevnev]

напомнило - kzbin.info/www/bejne/a6XOfpxtZ9xroJI

[@mikhailbo8589]

поток неупорядоченных мыслей. ...я его в домЕн засунул, в чистый дОмен.... судя по рассуждениям, автор ничего сложнее калькулятора не писал и ООП для него - это фреймворк типа спринга

[@ted_res]

Я не согласен с докладчиком. Если вам надо получить данные из репозитория, делаете mock для DAO, и возвращаете то, что считаете правильным. Никакого side effect. Если вам надо проверить какие-то специфические параметры, типа "является пользователь админом или нет", вынесите такие вычисления в отдельный сервис, и подключите чего через mock. Далее, что касается void-процедур и невозможности тестирования их содержимого. Да, если ваша процедура что-то вроде сделать_всё_хорошо(o:Object), то вы не покроете её тестами. И вы не сможете её контролировать ни в каком языке, ни на какой платформе, никакими средствами. Если вызываете процедуру, сделайте так, чтобы в ней не было вычислений, это сильно разгрузит тест. Интересно было бы узнать, как вы ставите задачи и принимаете код у разработчиков, есть предположение, что сначала даете волю писать, что вздумается, а потом пытаетесь все покрыть тестами. При таком подходе придется либо рефакторить как я описал выше, либо вообще забить на unit-тесты. Уверен, что при такой системе вы никогда не добьётесь от разработчиков, чтобы они выделяли чистую логику в FP.

[@yurim7756]

Так ваш мок и есть сайд эффект. Само ООП, состояния объектов - это практически сайд эффекты. То что он говорит, мне было понятно с начала, когда я узнал про депенденси инжекжин. Что такое сайдэффекты? Это когда вы функции будете отправлять одинаковые параметры, а она может возвращать разные ответы (по пути может еще что вокруг менять). А что такое интерфейс? Не это? Как-то он сумбурно объяснял, может вы не уловили суть. Суть весьма проста. Запихивая интерфейсы в некоторый класс/метод, который вы собираетесь тестить, вы по сути запихиваете кота в мешке, причем коты могут быть совершенно разные, когда вы тестируете, и когда это будет в реальности работать. Вы в тестах подумали, что дернув интерфейс (мок), он должен отработать одним образом, но в реальности он отработает другим. Вернет не то значение. (Что и есть сайдэффектом). И ваш юнит-тест по сути не гарантирует того, что в реальности система будет работать так же. А значит и ценность теста сильно снижается. У вас куча юнит-тестов, которые делаются ради тестов. А реальный кейс вы как раз можете пропустить. Это всё печально, но в ООП парадигме сложно что-то получше придумать. Возможно, вы скажете, что юнит-тесты обязаны тестить конкретный код, а не что там передают моки. И будете правы. Но все таки печалиться есть от чего. У вас будет перегруз юнит-тестами, их будет нереально дохрена, а по сути многие из них лишние из-за такой структуры кода. Как в математике, добавили множитель, добавили делитель. Каждый кусок кода окружен юнит-тестами в вакууме, с попыткой угадать как вести себя будут интерфейсы. Т.е. по тестам оверхед будет, и при каждом изменении требований, будет боль всю эту толпу тестов править. Многие из которых по сути на всякий случай. Сайд эффекты, они такие ) Сам на шарпе пишу, страдаю десятилетия ))

[@core__dump]

Добавлю своих 5 копеек на тему деконструкции TDD: kzbin.info/www/bejne/qX26hoWanKqWqKs