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

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

Эти методы позволяют не плодить лишние сеттеры

тут важно разобраться что делает этот тест хрупким.

Например... если у нас есть некий сервис который отправляет скажем email. И ты хочешь убедиться что сообщение туда ушло правильное. У тебя есть два способа это проверить:

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

То есть по факту разницы в этом случае нет. Что так что эдак тебе надо подсунуть зависимость и проверить "сайд эффекты". Буквально нет никакой разницы.

Хрупкость же возникает там где у нас "моки" юзаются не для проверки сайд эффектов (ну то есть не по назначению). Когда мы "стабим" не все методы наших зависимостей (то есть невозможно рефакторить не меняя тест). Когда мы игнорируем всякие Interface Segregation Principle и т.д. Когда мы не контролируем связанность системы.

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

Это оч плохо работает (или не очевидно как делать что бы было хорошо) если ты пишешь тесты после реализации.

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

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

В 5.2 добавили login link, все работает, но не дает полную авторизацию, роли не присваиваются, в чем причина ?

В том

самый бесталковый тут ?

Задавай тупой вопрос
@
Обижайся на тупой ответ

$this->createQueryBuilder('b')
->leftJoin(Soo::class, 's', 'WITH', 's.item = b.id')
->addSelect('PARTIAL s.{id, link}')
->getQuery()
->getArrayResult()

Делаю запрос с джойном без строгой связи в сущности.
В итоге, естественно, каша из сущностей b и s.
Можно как-то пометить сущности, чтобы я их уже нормально разобрал?

что такое "пометить"? что такое "разобрать"?

Если получать результат не массивом - классы я смогу проверить по instanceof. Там чотко понятно, что из "каши" b, а что Soo::class
А в массиве-то я не могу оценить, к какому Entity относится текущий набор данных.

мб ->addSelect('s.id AS sid', 's.link AS slink')

не оч понятно, зачем partial при getArrayResult

А, ну да. Что мешает подмешивать.

что вы используете для шифрования в симфони? мне надо передать в angular приложение шифрованную порцию данных. какие-то механизмы в симфони встроенные есть или какие-то бандлы используете? или вообще тупо openssl_ функции?

sodium crypto box

спасибо

что за?.. )

Наркоманы