я так заглушку для блокчейна поднимаю

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

даже не обязательно мок. стаб поднял и норм

тебе надо подменить Б

ок. подменили. а что с А и C?

дублировать тесты?

бля, пойду повешусь

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

ок. подменили. а что с А и C?

а их реальные юзать. Никогда не делал вещей вроде InMemoryRepository?

стабы

стабы юзать в интеграционных тестах можно

а вот моки - это ты в черный ящик влазишь

не я понял, перечитай заново условия

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

иногда это избыточно

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

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

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

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

о чем ты? ты либо мокаешь A и C либо у тебя нарушен закон деметры

короч

юнит тесты - проверка и проектирование контрактов

о чем ты? ты либо мокаешь A и C либо у тебя нарушен закон деметры

ооокей) и мы вернулись к тому что у нас тест, в котором А,B,C замоканы

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

ооокей) и мы вернулись к тому что у нас тест, в котором А,B,C замоканы

не вернулись

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

....если у тебя есть юнит тест который перестал что-либо проверять и начинает просто дублировать реализацию

ты его удаляешь и пишешь интеграционный

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

например я подменяю балансы юзеров в блокейне

я знаю что такое интеграционные тесты

я тебе говорю за конкретный кейс

а не абстрактные вещи

я тебе говорю за конкретный кейс

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

либо я чет не понимаю

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

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

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

а тест будет только поведение объекта проверять

и по хорошему тесты никогда не должны знать как тестируемый код работает.

function($data){ $result = $this->a->do($data); $result = $this->b->do($result); return $this->c->do($result); } A,C - зависят от базы, чтобы использовать реальные обьекты, нужны либо моки внутри A,C, либо поднимать базу B - зависит от внешнего сервиса, который тоже затыкается ты предлагаешь вместо A,B,C запихнуть моки. верно?

function($data){ $result = $this->a->do($data); $result = $this->b->do($result); return $this->c->do($result); } A,C - зависят от базы, чтобы использовать реальные обьекты, нужны либо моки внутри A,C, либо поднимать базу B - зависит от внешнего сервиса, который тоже затыкается ты предлагаешь вместо A,B,C запихнуть моки. верно?

интеграционный тест = подними базу

> B - зависит от внешнего сервиса, который тоже затыкается затыкать его надо только если его нельзя просто так дергать

и зачем это если обычный юнит тест справляется на 100% со своей задачей?

обычно 0 можно

и зачем это если обычный юнит тест справляется на 100% со своей задачей?

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

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

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

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

и тебе проверить надо что все в сумме работает

юнит тест тебе тут соврет

ну мол

ты юзаешь 2 объекта

$result = $this->a->do($data); return $this->b->do($result);

эти два объекта ничего не знают друг о друге и могут иметь разные контракты

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

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

то есть ничего

они ни проблемы не найдут ни помогут тебе

юнит тест для подобной фигни максимум поможет тебе с точки зрения декомпозиции

но как только ты разделишь эту штуку на тупой "менеджер" который тупо делигирует ответственность - юнит тест бесполезен

и штук у тебя таких в любом случае будет минимум

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

ну как.... наверное лучше чем без тестов вообще но всеж

....не убедил я тебя)

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

юнит тест тебе тут соврет

почему? у тебя идут 3 мока на А проверяется что в него приходит аргумент из тестируемого метода и он возвращает некий ответ а1 на Б проверяется что к нему пришли именно а1 и он возвращает б1 на С все тоже самое в итоге если ты удаляешь что-то из цепочки, или меняешь местами А и Б у тебя все ломается и тест об этом говорит

почему? у тебя идут 3 мока на А проверяется что в него приходит аргумент из тестируемого метода и он возвращает некий ответ а1 на Б проверяется что к нему пришли именно а1 и он возвращает б1 на С все тоже самое в итоге если ты удаляешь что-то из цепочки, или меняешь местами А и Б у тебя все ломается и тест об этом говорит

потому что это моки. Ты для них описал и тестируемый код ровно это и делает. Но не факт что это то что ожидается по контрактам объекта Б. Всякое может быть.

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

а это ровно то что делают интеграционные тесты

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

ERROR: S client not available

в теории так и надо делать, но не всегда это оправданно

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

не спорю) потому интеграционных тестов будет мало. Их не надо писать на каждый объект. Только на юзкейс

ребята, кто-нибудь использует teamcity для деплоя symfony проектов?

ребята, кто-нибудь использует teamcity для деплоя symfony проектов?

Используем

как деплоите parameters.yml?)

как деплоите parameters.yml?)

при первой инициализации создаю его ручками

а с новыми параметрами как?

тоже ручками

как нибудь это бы тоже через тим сити делать, не знаете есть ли способы?

Можно посмотреть в сторону переменных окружения

Типа какой-нибудь генератор parameters,yml на стороне тимсити и потом загрузка его на сервер

Нужно больше информации

как деплоите parameters.yml?)

все через env

Типа какой-нибудь генератор parameters,yml на стороне тимсити и потом загрузка его на сервер

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

Incenteev/composer-parameter-handler и переменные окружения

Какого после перевого же исключения перестает идти луп foreach?

В list`e элеметнов 15, одно исключение вылазит и стопится

а откуда именно исключение падает?

Ну вот из тех что я ловлю

Первые два

Я их посылаю из классов, сам

Имеет значение откуда они? Это кастомные исключения

стопится в смысле он выше где-то ловится?

Ну в смысле просто уже пишет мол у контроллера нет возврата

Короче дальше первого элемента листа не идет, если там исключение. А почти во всех элементах исключение т.к. фильтр жестокий

Как такое может быть?

а какой именно цикл то?

foreach list

foreach($list as $videoLink) ?

Да

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