декомпозиция это от общего к частному

при плохой декомпозиции (слишком детальной где не надо)

получается херовый класс

прям один класс получается

основная идея - смотреть на код с точки зрения клиентского кода

за счет этого

хз, я тебя не понимаю

что ты получаешь пользователем либы

что ты получаешь пользователем либы

даешь может?

ты получаешь правильный взгляд на зависимости

ты получаешь правильный взгляд на зависимости

какие к чету зависимости с точки зрения пользователей либы?

за счет зависимостей ты нормально декомпозируешь

попробуй еще раз... всеравно не понятно причем тут зависимости. Это зависимости тестируемого кода?

клиенту твоего клсса плевать на зависимости твоего кода

ну давай пример)

ты получаешь правильный взгляд на зависимости

А если либа полный шлак с точки зрения ооп, ну вроде одни утилитные классы к примеру или еще какая то шняга, как мокировать утилитные классы?

А если либа полный шлак с точки зрения ооп, ну вроде одни утилитные классы к примеру или еще какая то шняга, как мокировать утилитные классы?

а зачем их мокировать?

хотя... тут смотря что они делают конечно

а зачем их мокировать?

тестировать

но вообще я бы сказал что "такой код нельзя покрыть юнит тестами"

с моками все не так просто на самом деле

с ними легко попасть в ловушку в духе "твой тест ничего не тестит"

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

вот о чем я говорил https://pastebin.com/Yy8GxwYT по поводу зависимостей

какой код проще покрыть юнит тестами

то есть ты хочешь сказать что "юнит тесты форсят людей юзать IoC и late binding"?

пффф

нет

тогда ничего не понял

я хочу сказать чтобы покрывать код тестами

он должен быть пригоден

ваш кэп

в остальных случаях покрытие тестами станет болью

.....и к чему ты это все говоришь вообще?

к тому что зависимости это то что передается в контроллер

если в твоем классе разные зависимости которые сложно контролировать

1. я хочу что бы мои ребята писали юнит тесты 2. в идеале до имплементации 3. как раз таки что бы больше углубляться в декомпозицию и следить за open/close и lsp

то и покрывать это больно

к тому что зависимости это то что передается в контроллер

контроллеры у тебя откуда вообще взялись?

и причем тут юнит тесты?

речь просто о каше

контроллеры у тебя откуда вообще взялись?

конструктор

тут и без тестов боль будет

короч...

а тесты это серебрянная пуля

ты походу подустал малеха

которая решает все проблемы

серебрянных пуль нет

я показал 3 примера одного и того же

но одно покрыть тестами просто

другое нет

.....и к чему ты мне это показываешь, вот в чем вопрос?

у тебя уже если смотреть по связанности проблемы есть

а тесты - это клиент к тестируемому коду, и они будут страдать теми же болячками что и твой код

к тому что если люди не понимают что такое зависимости то будет все очень больно

допустим люди понимают что такое зависимости)))

тебя такой ответ устроит?

тогда и тесты будет писать не сложно

более того, большинство даже понимают что такое контракты

и проблем с тестами быть не должно

тогда и тесты будет писать не сложно

но почему-то их всеравно не пишут

и всеравно есть проблемы

и все вроде бы соблюдают IoC, пытаются думать в терминах SOLID, но тесты не пишут

ну тогда деспотия

вводи code coverage и запрещай его уменьшение, подход странный

code coverage ничего не говорит о том насколько у тебя все хорошо с тестами

но сделает так чтобы люди начали писать тесты

вот от слова совсем

ERROR: S client not available

code coverage ничего не говорит о том насколько у тебя все хорошо с тестами

я знаю

поэтому и написал странный

....короч

зато он заставит людей писать тесты

и возможно кому то понравится

"заставить" не выйдет

это ооооочень хреновая стратегия

ну то есть ты сейчас спрашиваешь

надо объяснить

ну то есть ты сейчас спрашиваешь

я не спрашиваю как мне кого-то заставить тесты писать

как мне заставить людей писать тесты, потому что я считаю что это надо, но только чтобы это не выглядело как заставить ?

я для этого воркшопы и усиленное код ревью делать буду

как мне заставить людей писать тесты, потому что я считаю что это надо, но только чтобы это не выглядело как заставить ?

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

я для этого воркшопы и усиленное код ревью делать буду

почему бы не брать на работу тех, кто не понимает смысла в написании тестов?

почему бы не брать на работу тех, кто не понимает смысла в написании тестов?

потому что тогда разработчиков годами буду искать

да лаадно

проще потратить месяц и обучить чем 3 месяца искать разработчика

я не верю что все так плохо

все ТАК плохо

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

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

более того, весь код что написан в проекте

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

они не против. Но как это происходит: 1. надо писать тесты 2. <пишем тесты, на это уходит много времени потому что мало практики> 3. расстраиваемся что все медленно и потиху забиваем на тесты

он был с твоим участием

и как следствие ты сам раньше не думал что надо писать тесты

более того, весь код что написан в проекте

у нас типа... больше одного проекта) аутсорс и все такое

а потом решил что надо и теперь хочешь чтобы люди тоже начали так считать, но думаешь как бы так сделать

несколько команд

чтобы они сами к этому пришли

они не против. Но как это происходит: 1. надо писать тесты 2. <пишем тесты, на это уходит много времени потому что мало практики> 3. расстраиваемся что все медленно и потиху забиваем на тесты

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

и как следствие ты сам раньше не думал что надо писать тесты

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

у нас типа... больше одного проекта) аутсорс и все такое

а ну сори