Size: a a a

2021 December 28

ПГ

Павел Г. in symfony
Не могу что то понять, с чем конкретно не согласны и что пытаетесь до меня донести...
источник

SP

Sergey Protko in symfony
тип того, пусть логика работы с данными будет там где данные.
источник

SP

Sergey Protko in symfony
ну у тебя есть оч странное мнение по поводу того что тестить сервисы и сущности надо по разному) то есть не оч понятны минусы которые ты выписал. Эти минусы не существуют для сервисов только если мы не тестируем сервисы или если тестируем - не тестируем их юнитами (интеграционные онли - зависимостей будет еще больше, а потому юниты вообще не осилить)
источник

ПГ

Павел Г. in symfony
Я не писал что по разному тестировать сервис и сущность. Я писал исключительно о тестировании сущности. Просто в случае передачи сервиса в метод, нужно ещё будет создавать сервис, а это усложнение подготовительной части тесторования метода сущности.
источник

SP

Sergey Protko in symfony
упоминание этого минуса значит что "есть другой вариант где этого минуса нет" - то есть "в случае сервиса нам почему-то не надо этот сервис никак готовить" - значит ты просто пишешь для сервисов всегда интеграционные тесты
источник

SP

Sergey Protko in symfony
то есть грубо говоря утрируя твой аргумент - "если передаем сервис в метод то это усложняет юниты - решение не писать юниты"
источник

ПГ

Павел Г. in symfony
В случае если сервис мы не передаем, то и не нужно его создавать в тестировании сущности. Но в обоих случаях сервис нужно тесировать отдельно в своём юнит тесте.
источник

ПГ

Павел Г. in symfony
Нет, я такого не имел ввиду
источник

SP

Sergey Protko in symfony
короч, нет минуса который ты описал. просто потому что в других вариантах этот же минус тоже существует (+ еще больше зависимостей). И существует он просто потому что у тебя есть зависимость и ты ее никак не уберешь. Единственный вариант игнорировать этот минус - не писать юнит тесты и полагаться на интеграционные.
источник

ПГ

Павел Г. in symfony
Если не передавать сервис в метод сущности - нет зависимости, тест проще, минуса этого нет
источник

SP

Sergey Protko in symfony
все это недостатки зависимостей а не где они юзаются
источник

SP

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

SP

Sergey Protko in symfony
спойлер - 90% людей которые пишут тесты но все еще полагаются на сеттеры в сущностях именно так и поступают - не пишут юниты и полагаются на интеграционные тесты
источник

SP

Sergey Protko in symfony
оставшиеся 10% несчастных пишут тесты дублирующие реализацию
источник

ПГ

Павел Г. in symfony
Это один позитивный интеграционный тест юзкейса/эндпоинта
источник

SP

Sergey Protko in symfony
который никак не убедится что ты чет хэшируешь
источник

SP

Sergey Protko in symfony
ну и опять же - при аутентификации у тебя хэшер где будет? тоже снаружи? тут ты не отделаешься одним позитивным кейсом
источник

ПГ

Павел Г. in symfony
Ну единственный способ гарантировать - это зашить в саму сущность или пригвоздить реализацию. Не спорю
источник

SP

Sergey Protko in symfony
ну а дальше я лишь хочу объяснить что те "недостатки" которые ты описал не недостатки. Точнее это все следствие "наличия зависимости" а не где оно юзается
источник

SP

Sergey Protko in symfony
мол то что ты перечислил звучит как "оправдание" почему мол я сеттеры юзаю и процедуры снаружи. Хотя по факту ситуация становится только хуже и единственная причиина по которой этих недостатков "не видно" - "я не пишу юниты на сервисы и проверяю абы что"
источник