кто как тестит

кто как структуру проекта ведет

я руками

или запрягаю своих подопечных

дорого выходит и медленно

у нас тестер есть

пишет автотесты

ну и разработчики тоже тестят

+ пхп юнит

тестер автоматизирует e2e тесты выходит?

окей, а сам проект, как примерно структуру проекта ведете? что покрываете интеграционными тестами? Что юнитами? Сеттеры в сущностях?

сетеры и гетеры в сущностях

покрываем всё

стремимся по крайней мере

сетеры и гетеры в сущностях

ясно понятно

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

на сервисы, менджеры, контроллеры, утилиты

команды

и т.д.

...контроллеры?

юнит тестами?

ага

зачем?

а почему нет?

ну то есть мы сейчас об одном и том же виде тестирования говорим?

ну там... мокать взаимодействие тестируемого объекта с внешним миром (все что вне объекта)

мокать поведение внешнее

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

ну из внешнего тестер пишет на эмуляторе

не понятно что проверяют такие тесты и как жить с тем что тесты полностью завязаны на реализацию

имитируя поведения юзера

имитируя поведения юзера

это e2e тесты это просто и не интересно

меня интересует что есть "юнит тест контроллера"

это примерно так же глупо как "юнит тест репозитория"

почему же?

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

дублируешь мол "эта штука должна дернуть эту штуку"

хотя тесты не должны о таких вещах знать

любой мелкий рефакторинг - тесты красные

не спорю)

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

двойная работа

другое дело если бы контроллеры покрывались интеграционными тестами

у меня к примеру так: - Model - тут почти все покрыто юнит тестами, репозитории интеграционными и если есть сервисы которые напрямую лезут в базу - тоже интеграционными. - Handler - высокоуровневая логика. По хэндлеру на юзкейс. Интеграционные тесты. - Service - инфраструктура. Почти полностью интеграционные тесты. Чутка юнитов - Http - по сути там контроллеры и трансформеры для API - интеграционные тесты

не спорю)

а зачем сеттеры в сущностях?

а где?

нигде, они не нужны. Ну у меня сеттеры еще в билдерах есть

хотя... я правильно понимаю что у тебя проекты - web, ну мол сайтики?

неа

точнее "есть место для forms"

нет

ни одного сайтика

и форм тоже нет

а ну тогда сеттеры вообще не нужны

ну хорошо, как ты создаешь обьекты?

вот например банальная регистрация

$user = User::builder() ->withEmail($email) ->withPassword($password, $passwordEncoder) ->withProfile(Profile::builder() ->withName($name) ->withBirthDay($birthDay) ->build() ) ->build();

о

пригодилось

cеку найду в гистах

https://gist.github.com/fesor/370b3486cf7ee96af34fcbb286bd6563

оно конечно не дописано, я про билдеры не написал ничего

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

https://gist.github.com/fesor/073e6928e13e38953b728460a85e8b26

вот еще пример на эту тему

можно еще подробить на объекты (например Credentials, Profile и User а не просто User) и будет еще прикольнее

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

не получился холивар?

ну ладно(

щас почитаю

могу сказать по своему опыту - чем расплывчатее требования, тем больше надо закладывать избыточности (больше дробить объекты и бизнес правила, больше следить за связанностью)

много было грабель пройдено

ну по поводу дробления

мы выносим в микро сервисы

если мы об одном и том же)

ну я о том что бы разделить объект User например а 4 разных класса

Credentials, User, Credentials, может еще для ролей отдельные

зависит от проекта

не, есть юзер, есть профиль, есть сеттинги

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