так?

ну да

ну, какое отношение имеет к find?

has нужен если в вашем dsl он используется

то как Серый его определил подталкивает к if (find($spec)) ... по крайней мере оно того не запрещает

для всего остально гоесть get с исключением

вот по этому я и предположил, что find часто используется так же как использовлся бы has

``` interface UserRepository { public function get(int $user): User; public function find(int $user): ?User; }

а get и find отличаются только эксепшеном? О.о

не ну не всегда

не, пожалуй нет

тогда пример был не очевидный, по крайней мере для меня :)

да я упоролся под вечер

у нас просто нет вроде "get"

ток фаинды

ну просто файнд по семантике может ничего не найти

а get обязан)

хм, а фаинды ли наши фаинды тогда ))

:D

моки в интеграционных тестах - это ОК?

как и всегда, зависит от ситуации.

опиши)

тест взаимодействия двух компонент, третий мешает

нет, он не мешает, но я не хочу его логику тестировать

ну, вообще ситуация абсолютно нормальная

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

вот этот процессор замокать

и смотреть, чтобы записи попадали в файл

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

зачем?

процессор юнитом покрывается

или всё-таки есть смысл?

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

хотя юнит тесты проходят

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

я не пишу логгер, я просто хотел пример привести

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

интеграционные тесты нужны не на процессор, а на несколько взаимодействующих компонентов

они потому и называются интеграционными

и опять же проверять что там пишут процессоры не нужно, нужно проверять факт того что кто-то что-то пишет

а конкретику проверяют уже юнит тесты

так что, мокать можно?

:D

в интеграционных ты можешь юзать контейнер даже, и мокать как угодно

ну другой пример, у меня компонент пишет в SQL базу и в в AMQP-очередь, и я хочу не писать в реальную очередь, а вместо неё stub

тестировать хочу запись в sql-базу

о, кстати, в интеграционных тестах симфони, как правильно поступать: использовать service container с конфигурацией сервисов из config_test.yml или инстанцировать сервисы вручную, конфигурируя из глобальных переменных, например?

смотри что быстрее и удобнее тебе будет

иногда проще весь контейнер поднять

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

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

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

щас сделан обычный враппер с реконнектом, но ворнинги задолбали)

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

приглуши ворнинги)

другие варианты?)

этот типа неэлегантный?

так а там кроме эксепшна ворнинг ещё?

PHP Warning: PDOStatement::execute(): MySQL server has gone away in /var/www/prod/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 91

https://github.com/facile-it/doctrine-mysql-come-back

и что, тут без ворнинга?

другие варианты?)

тебе не нравится мой вариант?

вдруг чет важное будет в ворнингах

именно при вызове метода враппера?

я имел в виду при вызове метода ворнинги ловить своим set_error_handler

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

может, wait timeout увеличить?

на несколько суток?)

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

ERROR: S client not available

открывает автоматически

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

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

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

?

задача для лентяев

есть проект без тестов

надо что бы тесты там были

написать тесты)

есть фикстуры которые покрывают прекондишены тест кейсов для смоука

есть люди владеющие мануальным тестированием

тесты надо написать только на API

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

есть php-vcr

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

у меня есть неделя-полторы

есть apiary который немного не актуален

как быть лентяем?

не писать тесты?)

это не тот вид лени

мне надо написать тесты с минимальными трудозатратами

исходя из того что есть (а есть немало чего)

необходим просто автоматизированный смоук API

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

неделя-полторы на что именно?

за полторы недели можно знатный кусок покрыть)

кто-то юзает функции в неймспейсах вместо статических в классах?

я вот до сих пор не юзаю и не могу придумать хоть одну причину почему так не стоит делать)

как пример есть Guzzle который этим не брезгует и нормально работает

точнее причины были - хреново работал пхпшторм, но уже давно все исправили

reactphp promise

resolve