Поздравляю авторов термина Dependency rejection и его адептов с переизобретением доменного слоя чистой архитектуры. Так держать, ещё несколько лет, и вы переизобретёте bounded contexts и вообще DDD. Догнать и перегнать ООП
Что если пюрному калькулятору требуется подтягивать разные данные в процессе расчёта, и какие именно - неизвестно до начала расчётов (либо тянуть их все непрактично, допустим в базе триллион записей)
да всё он расказал как по его мнению правильно и я с ним полностью согласен. когда вместо обычных данных суют депенденси в домейн - начинается жесть и каша
поток неупорядоченных мыслей. ...я его в домЕн засунул, в чистый дОмен.... судя по рассуждениям, автор ничего сложнее калькулятора не писал и ООП для него - это фреймворк типа спринга
Я не согласен с докладчиком. Если вам надо получить данные из репозитория, делаете mock для DAO, и возвращаете то, что считаете правильным. Никакого side effect. Если вам надо проверить какие-то специфические параметры, типа "является пользователь админом или нет", вынесите такие вычисления в отдельный сервис, и подключите чего через mock. Далее, что касается void-процедур и невозможности тестирования их содержимого. Да, если ваша процедура что-то вроде сделать_всё_хорошо(o:Object), то вы не покроете её тестами. И вы не сможете её контролировать ни в каком языке, ни на какой платформе, никакими средствами. Если вызываете процедуру, сделайте так, чтобы в ней не было вычислений, это сильно разгрузит тест. Интересно было бы узнать, как вы ставите задачи и принимаете код у разработчиков, есть предположение, что сначала даете волю писать, что вздумается, а потом пытаетесь все покрыть тестами. При таком подходе придется либо рефакторить как я описал выше, либо вообще забить на unit-тесты. Уверен, что при такой системе вы никогда не добьётесь от разработчиков, чтобы они выделяли чистую логику в FP.
Так ваш мок и есть сайд эффект. Само ООП, состояния объектов - это практически сайд эффекты. То что он говорит, мне было понятно с начала, когда я узнал про депенденси инжекжин. Что такое сайдэффекты? Это когда вы функции будете отправлять одинаковые параметры, а она может возвращать разные ответы (по пути может еще что вокруг менять). А что такое интерфейс? Не это? Как-то он сумбурно объяснял, может вы не уловили суть. Суть весьма проста. Запихивая интерфейсы в некоторый класс/метод, который вы собираетесь тестить, вы по сути запихиваете кота в мешке, причем коты могут быть совершенно разные, когда вы тестируете, и когда это будет в реальности работать. Вы в тестах подумали, что дернув интерфейс (мок), он должен отработать одним образом, но в реальности он отработает другим. Вернет не то значение. (Что и есть сайдэффектом). И ваш юнит-тест по сути не гарантирует того, что в реальности система будет работать так же. А значит и ценность теста сильно снижается. У вас куча юнит-тестов, которые делаются ради тестов. А реальный кейс вы как раз можете пропустить. Это всё печально, но в ООП парадигме сложно что-то получше придумать. Возможно, вы скажете, что юнит-тесты обязаны тестить конкретный код, а не что там передают моки. И будете правы. Но все таки печалиться есть от чего. У вас будет перегруз юнит-тестами, их будет нереально дохрена, а по сути многие из них лишние из-за такой структуры кода. Как в математике, добавили множитель, добавили делитель. Каждый кусок кода окружен юнит-тестами в вакууме, с попыткой угадать как вести себя будут интерфейсы. Т.е. по тестам оверхед будет, и при каждом изменении требований, будет боль всю эту толпу тестов править. Многие из которых по сути на всякий случай. Сайд эффекты, они такие ) Сам на шарпе пишу, страдаю десятилетия ))
Поздравляю авторов термина Dependency rejection и его адептов с переизобретением доменного слоя чистой архитектуры. Так держать, ещё несколько лет, и вы переизобретёте bounded contexts и вообще DDD. Догнать и перегнать ООП
Очень сложно слушать речь докладчика, когда идёт русский язык с множеством вставок английских слов: "мес", "артикл", "реджектить", "миксить" итд
согласен. слушать не возможно. надеюсь за эти 4 года спикер пересмотрел свои взгляды на лексикон при выступлениях
Очень режет слух. Или уже выступай на английском или на русском но не надо слонять англ слова.
Что если пюрному калькулятору требуется подтягивать разные данные в процессе расчёта, и какие именно - неизвестно до начала расчётов (либо тянуть их все непрактично, допустим в базе триллион записей)
Фри монады.
То же интересно, как можно применять идеи из доклада для таких задач. @megasuperlexa2 удалось что-то узнать в этом направлении?
fuzzy testing думаю в этом случае подойдет
@@bonumsignum7017 если коротко, как именно фри монады позволяют решить эту проблему?
@@АнимусАнанимус Ты не делаешь сайдеффекты, ты их описываешь, а интерпретатор фри монады их уже выполняет.
Все плохо, вот вам пример. А как правильно мы вам не покажем, сами думайте.
да всё он расказал как по его мнению правильно и я с ним полностью согласен. когда вместо обычных данных суют депенденси в домейн - начинается жесть и каша
поток неупорядоченных мыслей. ...я его в домЕн засунул, в чистый дОмен.... судя по рассуждениям, автор ничего сложнее калькулятора не писал и ООП для него - это фреймворк типа спринга
напомнило - th-cam.com/video/5tkMi72w8j0/w-d-xo.html
Я не согласен с докладчиком. Если вам надо получить данные из репозитория, делаете mock для DAO, и возвращаете то, что считаете правильным. Никакого side effect. Если вам надо проверить какие-то специфические параметры, типа "является пользователь админом или нет", вынесите такие вычисления в отдельный сервис, и подключите чего через mock. Далее, что касается void-процедур и невозможности тестирования их содержимого. Да, если ваша процедура что-то вроде сделать_всё_хорошо(o:Object), то вы не покроете её тестами. И вы не сможете её контролировать ни в каком языке, ни на какой платформе, никакими средствами. Если вызываете процедуру, сделайте так, чтобы в ней не было вычислений, это сильно разгрузит тест.
Интересно было бы узнать, как вы ставите задачи и принимаете код у разработчиков, есть предположение, что сначала даете волю писать, что вздумается, а потом пытаетесь все покрыть тестами. При таком подходе придется либо рефакторить как я описал выше, либо вообще забить на unit-тесты. Уверен, что при такой системе вы никогда не добьётесь от разработчиков, чтобы они выделяли чистую логику в FP.
Так ваш мок и есть сайд эффект. Само ООП, состояния объектов - это практически сайд эффекты. То что он говорит, мне было понятно с начала, когда я узнал про депенденси инжекжин.
Что такое сайдэффекты? Это когда вы функции будете отправлять одинаковые параметры, а она может возвращать разные ответы (по пути может еще что вокруг менять). А что такое интерфейс? Не это?
Как-то он сумбурно объяснял, может вы не уловили суть. Суть весьма проста. Запихивая интерфейсы в некоторый класс/метод, который вы собираетесь тестить, вы по сути запихиваете кота в мешке, причем коты могут быть совершенно разные, когда вы тестируете, и когда это будет в реальности работать. Вы в тестах подумали, что дернув интерфейс (мок), он должен отработать одним образом, но в реальности он отработает другим. Вернет не то значение. (Что и есть сайдэффектом). И ваш юнит-тест по сути не гарантирует того, что в реальности система будет работать так же. А значит и ценность теста сильно снижается. У вас куча юнит-тестов, которые делаются ради тестов. А реальный кейс вы как раз можете пропустить.
Это всё печально, но в ООП парадигме сложно что-то получше придумать.
Возможно, вы скажете, что юнит-тесты обязаны тестить конкретный код, а не что там передают моки. И будете правы. Но все таки печалиться есть от чего. У вас будет перегруз юнит-тестами, их будет нереально дохрена, а по сути многие из них лишние из-за такой структуры кода. Как в математике, добавили множитель, добавили делитель. Каждый кусок кода окружен юнит-тестами в вакууме, с попыткой угадать как вести себя будут интерфейсы. Т.е. по тестам оверхед будет, и при каждом изменении требований, будет боль всю эту толпу тестов править. Многие из которых по сути на всякий случай. Сайд эффекты, они такие ) Сам на шарпе пишу, страдаю десятилетия ))
Добавлю своих 5 копеек на тему деконструкции TDD: th-cam.com/video/sLWURdgEcrI/w-d-xo.html