ПГ
Если без обёртки то пишется не юнит тест, где qb НЕ мокается и тесты реально ходят в базу за реальными данными
Ну так да.
Size: a a a
2021 March 18
КГ
А кому и где нужна не портабельность?
Мне не нужна. Где бы ни работал ни одному проекту она была не нужна
AD
Разница есть. Тут Фесор часто набрасывает, что важно все методы реализовывать. Я правда нупь и пока сам не понял суть проблемы
Ты не гарантируешь того, что тест не будет вызывать другие методы.
Phpunit для "неконтролируемых" методов будет возвращать просто null, что может привести к нежелательным последствиям (что не было предусмотрено тестом).
Поэтому конфигурировать все методы - значит обозначить все кейсы использования и дать понять - что ты "контролируешь ситуацию"
Phpunit для "неконтролируемых" методов будет возвращать просто null, что может привести к нежелательным последствиям (что не было предусмотрено тестом).
Поэтому конфигурировать все методы - значит обозначить все кейсы использования и дать понять - что ты "контролируешь ситуацию"
ПГ
Ты не гарантируешь того, что тест не будет вызывать другие методы.
Phpunit для "неконтролируемых" методов будет возвращать просто null, что может привести к нежелательным последствиям (что не было предусмотрено тестом).
Поэтому конфигурировать все методы - значит обозначить все кейсы использования и дать понять - что ты "контролируешь ситуацию"
Phpunit для "неконтролируемых" методов будет возвращать просто null, что может привести к нежелательным последствиям (что не было предусмотрено тестом).
Поэтому конфигурировать все методы - значит обозначить все кейсы использования и дать понять - что ты "контролируешь ситуацию"
Ну кстати здраво звучит. Когда мокаем один метод, значит мы знаем о реализации тестируемого класса.
КГ
Ну если данных мало и можно себе позволить, то ок
Не вижу корреляции с размером данных. Базы обычно не меняются набегу.
Я на пет проекте мускул поменял на постгрес. Было достаточно больно, но эту боль я бы никак не предупредил заранее
Я на пет проекте мускул поменял на постгрес. Было достаточно больно, но эту боль я бы никак не предупредил заранее
КГ
Короче выходит что все дробить надо на "команды" XD
Этот концепт я тоже так и не понял
ПГ
Этот концепт я тоже так и не понял
Ну типо максимальный SRP. Ничто ни с чем не связано, каждый класс только 1 метод - одна ответственность. Правда мне кажется DI контенйер будет задыхаться на чуть более чем среднем проекте при сборке.
КГ
Ну типо максимальный SRP. Ничто ни с чем не связано, каждый класс только 1 метод - одна ответственность. Правда мне кажется DI контенйер будет задыхаться на чуть более чем среднем проекте при сборке.
Я поигрался, получилась фигня какая то.
Ну типа вот есть контроллер, его задача конвертировать http запрос в запрос к домену (грубо говоря). Есть консольная команда, у неё такая же задача, только конвертировать консольный запрос.
И там и там я достал какую то сущность и вызвал у неё метод. Зачем мне и там и там порождать команду, чтобы потом в хендлере вызвать метод?
Ну типа вот есть контроллер, его задача конвертировать http запрос в запрос к домену (грубо говоря). Есть консольная команда, у неё такая же задача, только конвертировать консольный запрос.
И там и там я достал какую то сущность и вызвал у неё метод. Зачем мне и там и там порождать команду, чтобы потом в хендлере вызвать метод?
ПГ
Я поигрался, получилась фигня какая то.
Ну типа вот есть контроллер, его задача конвертировать http запрос в запрос к домену (грубо говоря). Есть консольная команда, у неё такая же задача, только конвертировать консольный запрос.
И там и там я достал какую то сущность и вызвал у неё метод. Зачем мне и там и там порождать команду, чтобы потом в хендлере вызвать метод?
Ну типа вот есть контроллер, его задача конвертировать http запрос в запрос к домену (грубо говоря). Есть консольная команда, у неё такая же задача, только конвертировать консольный запрос.
И там и там я достал какую то сущность и вызвал у неё метод. Зачем мне и там и там порождать команду, чтобы потом в хендлере вызвать метод?
Ну если одна задаа, просто разный источник данных - то обертка (Команда/хэндлер), так как логика одна DRY. Две команды и два хэндлера - смысла не вижу.
КГ
Каким образом? Вся логика скрыта в методе сущности. Логика получения сущности из базы в двух местах это не про DRY
ПГ
Каким образом? Вся логика скрыта в методе сущности. Логика получения сущности из базы в двух местах это не про DRY
Ну если ничего нет, кроме вызова и все инкапсулировано в сущности, то и хэндлер наверное не нужен ) лишняя возня
КГ
И вообще пришел к мнению, что прямая отправка команды/ивента в MessageBus->dispatch это прям хрень какая то.
Код на говно похож. Но возможно простоя олень и не разобрался.
Вот сущности кидают ивенты, их отправка в messageBus скрыта под капотом. А руками размазывать инфраструктуру выглядит не очень
Код на говно похож. Но возможно простоя олень и не разобрался.
Вот сущности кидают ивенты, их отправка в messageBus скрыта под капотом. А руками размазывать инфраструктуру выглядит не очень
ПГ
И вообще пришел к мнению, что прямая отправка команды/ивента в MessageBus->dispatch это прям хрень какая то.
Код на говно похож. Но возможно простоя олень и не разобрался.
Вот сущности кидают ивенты, их отправка в messageBus скрыта под капотом. А руками размазывать инфраструктуру выглядит не очень
Код на говно похож. Но возможно простоя олень и не разобрался.
Вот сущности кидают ивенты, их отправка в messageBus скрыта под капотом. А руками размазывать инфраструктуру выглядит не очень
Все ивенты сразу в бас? Мне кажется все же иногда нужна синхронность.
КГ
Все ивенты сразу в бас? Мне кажется все же иногда нужна синхронность.
эм, зачем? Я не смотрел, но чаще всего после флаша 1 ивент есть