Сервис возможно нужно будет создавать через Di, ну банально удобнее, или зависим от чего то "внешнего". Придётся делать мок или поднимать приложение для Di. В общем я бы сказал, что по ситуации ну и + к шансу передачи если это доменный сервис, без сложной сборки.

Если логика сущности сильно зависит от сервиса, то понятно, что деваться некуда

То есть с сервисами ты просто не будешь писать юниты и потому проще?)

С передачей сервиса в метод сущности, нужно собирать этот сервис или делать мок. Это уже усложнение теста.

Сча дойду до ноута попробую расписать в чем разница. Но в двух словах - ты по сути сейчас рассуждаешь с позиции "пишу тесты или не пишу тесты"

В обоих моих вариантах тесты есть. В одном - нужно создавать сервис/мок, в другом - нет.

Давай рассуждать почему в одном случае ты можешь себе это позволить а в другом нет. И вообще должны ли юниты полагаться на контейнер и если нет то почему

Юниты без контейнера желательно - для скорости

Не для скорости, попробуй ещё раз

Для однозначности и независимости от чего либо?

давай порассуждаем немного. У меня два вопроса:

- почему ты видишь разницу в том как объекты для теста создаются в случае сервиса и в случае сущности? Должна ли быть разница? Или эта разница обусловлена только "я могу" но по факту "не должен".
- на счет "не тот энкодер передал" - ты так же можешь "не тот энкодер" в настройках сервиса указать. Есть ли разница с точки зрения поведения системы? ну то есть, будешь ли ты тестить именно то что "именно тот энкодер" или тебя интересует только проверить что контракты соблюдены? Ведь если ты соблюдаешь правила проектирования разницы в плане контрактов от разных реализаций быть не должно. Мы для того интерфейсы и используем.

1. Я не вижу разницы. Мой поинт в том, что при тестировании сущности без зависимости на сервис, мне не нужно создавать этот сервис. Подготовительную часть теста писать легче.
2. Изначальный вопрос ( который был несколько дней назад) - это как однозначно всегда хэшировать пароль. В целом передача интерфейса хэшера в setPassword не даёт 100 процентную гарантию этого. Но даёт более понятный интерфейс метода.

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

почему не дает 100% гарантии?

Я смогу что угодно запихать под этот интерфейс.

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

в целом это тоже выход - никто не мешает внутри сущности юзать напрямую password api - как бы это достаточно стабильная абстракция и весьма удобная. "энкодеры" имеет смысл если у тебя легаси и "свои" способы хэши соли хранить

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

но с позиции управления рисками - то что ты озвучил несущественно. Это проблема на уровне "накосячил с конфигурациями".

я знаю много людей которые пытаются такие вот риски конфигураций контролировать тестами - это плохая идея. Дорого и бесполезно

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