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

жостка

Я тут недавно глянул на уровень зп в дании. Так вот там ресепшионист получает в два раза больше чем software engineer

Software engineer где-то там внизу страницы

Пора переучиваться )

Пора переучиваться )

Работа это в первую очередь призвание, а потом уже доход)

А если призвание иметь доход

Тогда наверное это в бизнес надо

Добрый, подскажите пжл есть 2 контейнера поднятых рядом, смотрят на 1 бд в одном контейнере есть сущность class A { string $a; } в другом контейнере есть сущность class B { string $b; A $a } мне надо копировать сущность А из одного контейнера в другой? (ну это бред на мой взгляд)

микросервисы? а как общаются между собой микросервисы?

так то можно хоть сериализовать в файл

А если призвание иметь доход

Тут главное чтоб доход не "поимел" тебя :) (шутка) А так это не призвание, это желание, и чтоб максимально эффективно его реализовать, нужно заниматься любимым делом, а занимаешься ты при этом бизнесом или работаешь на дядю не важно, главное гореть своим делом, тогда окружающие сами будут нести тебе деньги / предлагать должности. Примерно так это работает в большенстве случаев :)

И снова здратути) Вопрос: как замокать сервис в синк вызове мессенджера ?) В тестах при замене сервиса у KernelBrowser , мок не попадает в контейнер который используется синхронным мессенджером.

И снова здратути) Вопрос: как замокать сервис в синк вызове мессенджера ?) В тестах при замене сервиса у KernelBrowser , мок не попадает в контейнер который используется синхронным мессенджером.

дратути это интеграционный тест и не надо ничего мокать надо потом почистить

дратути это интеграционный тест и не надо ничего мокать надо потом почистить

У меня сервис наружу ходит, я хотелбы замокать

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

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

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

Не могу, проблема в том, что в хэдлер мессенджера попадает реальный сервис, в этом проблема

так тестируй хендлер, а не мессенжер

мессенжер не ты писал

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

Согласен, юнит был бы лучше. Но для юнита надо распедаливать норм архитектуру, то что я написал в этом хэндлере, пока чет мозга не хватает. Тестирую общую работу обработки данных полученных извне. Вот эти данные и хочу мокнуть

так тестируй хендлер, а не мессенжер

Ну вот пока так и делаю, но хотелось бы вызвать стартовый хэдлер и чтобы завелась вся цепочка хэдлеров (которые вызываются через очередь), а не вручную дергать поочереди

так, ещё раз или юнит тест, или интеграционный если ты боишься, что у тебя разваливается стек миддлвари и сообщения не доходят, то это не юнит тест

так, ещё раз или юнит тест, или интеграционный если ты боишься, что у тебя разваливается стек миддлвари и сообщения не доходят, то это не юнит тест

Я и не говорил что я тестирую юнит

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

Я говорил что было бы хорошо хэндлер на простые составляющие распедалить чтобы потом юнитить, но как распедалить - пока нема. Ну и хотелось бы просто смок тест запустить

просто замени в конфиге контейнера, где бы он не лежал, определение сервиса, укажи другой аргумент

для тестового энва

просто замени в конфиге контейнера, где бы он не лежал, определение сервиса, укажи другой аргумент

Охото динамику, чтобы для разных тестов разные моки

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

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

Как это решает мою проблему?

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

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

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

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

То что я мокаю в тестах - не оказывается в хэдлере, если его дергает мессенджер

Если я дергаю хэдлер сам - моки норм срабатывают

Ну и сам хэдлер я не могу получить (в случае с мессенджером), чтобы что то там в паблик сунуть

Ребята, как вы пишете тесты? Меня интересуют тесты API (сходи по такому-то url, получи такой-то ответ). Нормально ли использовать отдельные файлы для каждого эндпоинта? Например, /api/user/{id}/categories - один файл, /api/user/{id}/groups - другой файл и тд. И нормально ли использовать разные фикстуры для разных тестов? Вот для примера выше мне разные наборы данных нужны, например

Ребята, как вы пишете тесты? Меня интересуют тесты API (сходи по такому-то url, получи такой-то ответ). Нормально ли использовать отдельные файлы для каждого эндпоинта? Например, /api/user/{id}/categories - один файл, /api/user/{id}/groups - другой файл и тд. И нормально ли использовать разные фикстуры для разных тестов? Вот для примера выше мне разные наборы данных нужны, например

И так и сяк пишем, оба способа норм . Разные фикстуры заводить в теории лучше, на практике сложнее. Поэтому юзаем одни на все тесты

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

е2е полезная штука

Ребята, как вы пишете тесты? Меня интересуют тесты API (сходи по такому-то url, получи такой-то ответ). Нормально ли использовать отдельные файлы для каждого эндпоинта? Например, /api/user/{id}/categories - один файл, /api/user/{id}/groups - другой файл и тд. И нормально ли использовать разные фикстуры для разных тестов? Вот для примера выше мне разные наборы данных нужны, например

https://github.com/thephpleague/openapi-psr7-validator

использую доволен как слон

это полезная штука, но чутка не про то: человеку надо иметь уверенность, что /users/1 будет иметь "name": "John"

пхпюнит вроде умеет сравнивать джсоны

из коробки

да что угодно умеет, вопрос не о том-то

Всем привет. Подскажите плз как лучше реализовать такую задачу - в проекте есть большое количество "настроек", мы назвали их Option. Что-то вроде feature switcher Они хранятся в файле (настройки по умолчанию), затем переписываются настройками из БД. И если в запросе от пользователя пришли другие options, они заменяют уже имеющиеся. Далее в коде нужно работать с этими options. Удобно не дёргать их каждый раз из DI, а вызвать Option::get('optionName'). Как лучше их инициализировать? На синглтон похоже, что совсем не гуд...

$optionService->resolve(FooOptionEnum::OptName, $request)

и этот ваш опшнсервис везде таскать зависимостью

$optionService->resolve(FooOptionEnum::OptName, $request)

Это заменит текущие option-ы из запроса. Ок, это не проблема. А дальше по коду как их дергать?

и этот ваш опшнсервис везде таскать зависимостью

Вот это не удобно. Других вариантов нет?)

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

Вот это не удобно. Других вариантов нет?)

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

решаете вы в любом случае

Печально) Такая конструкция тоже будет говно https://github.com/IndraGunawan/facade-bundle#creating-facade ?

однозначно

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

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

Похоже что-то делаем не так, по этому и решил задать вопрос)

окей, вернемся в начало: почему неудобно внедрять зависимость? можете показать примеры кода? я смутно догадываюсь, что это может быть нужно в out-of-container-scope классах, типа в сущности

тогда это плохо, да, но решаемо

окей, вернемся в начало: почему неудобно внедрять зависимость? можете показать примеры кода? я смутно догадываюсь, что это может быть нужно в out-of-container-scope классах, типа в сущности

Почему не удобно - потому-что нужно будет прокинуть его вообще везде. В каждый сервис, контроллер. Вот и подумали, что можно условно вытащить из ядра в любом участке кода. Типа $kernel->getOption('optionName') или как я писал Option::get('optionName')

Но получилось не очень)

в кернел точно не надо, ваш код обязан ничего ни про какие кернелы не знать

Понял. Спасибо!

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

это будет разница в одну строку (если у вас пхп 8+) - аргумент конструктора. внутри же нет разницы какой метод вызывать

Подскажите, пожалуйста, как в функциональных тестах (используется codeception) можно проверить, что массив, который возвращается не содержит объектов с определенным айди?

Подскажите, пожалуйста, как в функциональных тестах (используется codeception) можно проверить, что массив, который возвращается не содержит объектов с определенным айди?

Перебрать все объекты и проверить их айди?

ну я думаю, может есть что-то типа cantSeeResponseContainsJson

Подскажите, пожалуйста, как в функциональных тестах (используется codeception) можно проверить, что массив, который возвращается не содержит объектов с определенным айди?

А он куда возвращается? Либо перебирать, либо это положить в фейковый/тестовый репозиторий и там уже https://codeception.com/docs/modules/Doctrine2.html#dontSeeInRepository Но последний вариант больше выглядит как костыль.

$optionService->resolve(FooOptionEnum::OptName, $request)

@ykweb Мне каежтся для удобства можно еще прикрепить над эти делом фасадик, который под капотом достает $request + сделать методы, для автокомплита будет удобнее, наверное. Итого будет $requestOptionResolver->optName()

Ну и проще будет искать, где какая опция юзается. Upd Хотя наверное можно и по вызову констант/enum.

@ykweb Мне каежтся для удобства можно еще прикрепить над эти делом фасадик, который под капотом достает $request + сделать методы, для автокомплита будет удобнее, наверное. Итого будет $requestOptionResolver->optName()

Что-то такое и получилось. Для поиска опций enum используем, оч удобно)

Есть у кого пример как в симфе асинхронно грузить файлы с помощью родного хттп клиента? Не в память, прямо в файл

в доке 1 файл тока мультиплексом. а надо несколько сразу.

Есть у кого пример как в симфе асинхронно грузить файлы с помощью родного хттп клиента? Не в память, прямо в файл

Впервые такой кейс прочитал, интересненько. А почему через мультиплекс не получится несколько файлов? Карту ресурсов и респонсов сохраняешь, потом сохраняешь чанки по ним в ресурсы файлов

может и получится, но код будет лютое говнище )

может и получится, но код будет лютое говнище )

Ну это как напишешь)

да не, дерьмо короче этот хттп клиент

😅

какие-то чанки, миллиард ифов, что за говно? )