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

потому что ты приложение полностью загружаешь

скорее это даже не интеграционное а функциональное

скорее это даже не интеграционное а функциональное

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

Ребята помогите найти ошибку Пробую писать логи с помощью monolog Если делаю так $log = new Logger('conversion'); $log->pushHandler(new StreamHandler('log.log', Logger::INFO)); $log->error("Заявка $num " . $data['period'] . "не выполнена"); то все работает, лог пишется Пытаюсь сделать чтобы все настройки хранились в конфиге в config.yml monolog: handlers: conversion: type: stream path: "%kernel.logs_dir%/conversion.log" level: info channels: conversion в service.yml monolog_web_processor: class: Symfony\Bridge\Monolog\Logger tags: - { name: monolog.logger, channel: conversion } сообщение не пишется в файл, а ввыводится в консоле (консольная команды выполняется)

ну и в приведенном примере бесполезный юнит тест)

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

моки это весело, но конкретно тут я не вижу осбо от них профита

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

вообще есть чудная вещь CommandTester в симфе

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

ну такое.... меня больше количество моков смущает

в целом - это юнит тест

так как он проверят один юнит - запускалку команд

ребята может кто-то подскажет по моему вопросу чуть выше

привет, подскажите как решить такую проблему. Есть сущность Product, есть класс который эту сущность сохраняет, внутри доктрина $em->persist($product);$em->flush(); Есть так же импорт товаров, в нем соответственно я не могу использовать класс для сохранения так как в импорте пачками persist и только потом flush. Получается что два разных места которые делают одно и тоже, сохраняют товар. Но код разный, а хочется сохранять одним сервисом везде. Как такое правильно разрулить архитектурно?

никогда не делай flush в сервисах

ну или у тебя есть сервис который делает flush

то есть всегда нужно будет использовать два сервиса?

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

контроллер например

или если у тебя есть циклик где надо пакетную обработку делать

то после каждой итерации или после части итераций

понял, спасибо!

ну и еще - ты же вкурсе что для "обновления" тебе не надо делать persist?

да)

может быть когда-нибудь в doctrine добавят метод save который минует unit-of-work

тогда можно будет уже чуть по другому делать

Ребята помогите найти ошибку Пробую писать логи с помощью monolog Если делаю так $log = new Logger('conversion'); $log->pushHandler(new StreamHandler('log.log', Logger::INFO)); $log->error("Заявка $num " . $data['period'] . "не выполнена"); то все работает, лог пишется Пытаюсь сделать чтобы все настройки хранились в конфиге в config.yml monolog: handlers: conversion: type: stream path: "%kernel.logs_dir%/conversion.log" level: info channels: conversion в service.yml monolog_web_processor: class: Symfony\Bridge\Monolog\Logger tags: - { name: monolog.logger, channel: conversion } сообщение не пишется в файл, а ввыводится в консоле (консольная команды выполняется)

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

+ зарегать это канал еще нужно

привет, подскажите как решить такую проблему. Есть сущность Product, есть класс который эту сущность сохраняет, внутри доктрина $em->persist($product);$em->flush(); Есть так же импорт товаров, в нем соответственно я не могу использовать класс для сохранения так как в импорте пачками persist и только потом flush. Получается что два разных места которые делают одно и тоже, сохраняют товар. Но код разный, а хочется сохранять одним сервисом везде. Как такое правильно разрулить архитектурно?

не, так не катит. если ты сделаешь импорт на 5 тыс записей, а потом flush, то что-то может пойти не так) в этом случае все пачками обновлять нужно http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/batch-processing.html#bulk-inserts

+ зарегать это канал еще нужно

а по подробнее можно?

прописать в конфиге новый поток

monolog: channels: ['foo', 'bar']

и вместо @logger юзать @monolog.logger.foo

удобно кстати с разными каналами

может и удобно. но что-то не получается :)

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

А как без моков протестировать абстрактный класс?

И как тут база данных завязана? :(

может и удобно. но что-то не получается :)

ты логгер правильный юзаешь?

скорее всего нет раз файл не пишется

покажи конфиг сервиса где ты инжектишь логгер

monolog_web_processor: class: Symfony\Bridge\Monolog\Logger tags: - { name: monolog.logger.conversion, channel: conversion }

так это процессор

@Enleur Спасибо, за комментарий! @rodneyspn Спасибо за совет. Как я понял вы не против моего небольшого сообщения. Нам нужны на проект один PHP разработчик с хорошими знаниями symfony и/или Zend Проект логистического характера, система автоматизации. Проект не быстрый соответственно занятость гарантируем на несколько месяцев вперёд точно. Full-time не подразумеваем, 3-4 часа в день - норм. Оплата достойная, проект российский, платим по средне-российской ставке для удалённых исполнителей (800-1000 рублей в час). Есть много иностранных проектов там платим больше, но это про будущее. Условия: 1. Работа удалённая и график свободный(есть правда некоторые периоды времени каждый день когда Вы должны быть на связи) 2. Работа сдельная по оговорённой ставке 3. Все задачи проходят через Redmine с крайне подробным описанием и для всего у нас есть регламент. 4. Наши клиенты это крупные компании(Ростелеком, Гонка Героев, Водоканал, Международный Юридический Форум, Пулково ...), мы не запрещаем Вам рассказывать, что это сделали Вы =) Контакты либо через почту m@mobecan.com либо тут в личку. В сообщении прошу указать портфолио.

только symfony, а не symphony)

@Enleur Спасибо =) Привычка

так это процессор

а что должно быть?

это ты делаешь процессор для конкретного канала типа monolog.processor.uid: class: Monolog\Processor\UidProcessor tags: - { name: monolog.processor, method: __invoke, channel: "foo" }

а тебе нужно именно писать в нужный канал

А как без моков протестировать абстрактный класс?

в интеграционных тестах тебе не надо юзать абстрактные классы

а в юнитах - это совсем другой разговор

А почему этот тест бесполезен? Разве эту вещь не надо было тестировать?

абстрактный класс тестировать нужно в принципе только если он предназначен для чьего-то еще расширения

А почему этот тест бесполезен? Разве эту вещь не надо было тестировать?

тест дублирующий реализацию - бесполезный тест потому что он ничего не проверяет

А он для этого и предназначен :(

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

Ну там тестируется раннер, реализация раннера же не замочена :(

Ну там тестируется раннер, реализация раннера же не замочена :(

не ты не понял

Тогда от обратного

когда моки используются?

когда нужна верификация вызовов

нет

А у меня не та ситуация?

Так-с

ERROR: S client not available

Я путаюся

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

ну верификация

НО!

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

нет логики

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

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

ну хзхз, проще юнит

чем поднимать целый интеграционный для проверки

ну хзхз, проще юнит

он у тебя ничего не проверяет

ты поправишь реализацию - тебе придется править тесты

править моки

проверяет что вызываются зависимости

че это моки править?

ну блин

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

у тебя есть сервис который должен сделать A -> B -> C и вернуть результат C

у тебя есть сервис который должен сделать A -> B -> C и вернуть результат C

то есть

фасад

function foo($data) { $tmp = $this->a->doStuff($data); $tmp = $this->b->doStuff($data); return $this->c->doStuff($data); }

вот так да?

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

а a, b и c и так покрыты юнит тестами

потому все что мы можем сделать - проверить что все в сборке работает

ну скажем function($data){ $result = $this->a->do($data); $result = $this->b->do($result); return $this->c->do($result); }

и вот для этого пишем один маленький интеграционный тест с одним позитивным тест кейсом

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

1 интеграционный тест на 3 набора юнит тестов

как по мне все вполне в терминах 10% интеграционных тестов

1 интеграционный тест на 3 набора юнит тестов

а если сложно его поднимать? давай для примера возьмем вызов апи какого-то сервис A у нас отвечает за преобразование $data в запрос сервис B за отправку запроса на внешний сервис сервис C разбирает то что верунл сервис и возвращает DTO чтобы такое проверить полностью тебе нужно замокать эндпоинт на B, подобрать данные для $data и проверить то что вернул C. хотя все это уже протестировано, но по отдельным компонентам

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