D
теортически достаточно юнитов, если проверить что событие было published в некую очередь, а потом юниты на сам консьюмер
но я согласен с вами, функциональные позволяют убедиться в том что целиком это все работает как надо
Size: a a a
2020 October 04
IG
На подписчики не пишу юнит тесты. Это чисто сервисный код.
В конце теста создания, например, добавляю ожидание на нужный сервис, который должен был вызван по итого. Как он будет вызван уже не интересно.
В конце теста создания, например, добавляю ожидание на нужный сервис, который должен был вызван по итого. Как он будет вызван уже не интересно.
IG
user->makeVisible()
user->makeFuckable()
em->flush
publish(event($user))
user->makeFuckable()
em->flush
publish(event($user))
Либо явно, либо это спрятать в паблишер.
D
Либо явно, либо это спрятать в паблишер.
опасно прятать в паблишер, тогда код метода который работает с юзером будет зависеть от паблишера, потому что флаш будет именно там
D
На подписчики не пишу юнит тесты. Это чисто сервисный код.
В конце теста создания, например, добавляю ожидание на нужный сервис, который должен был вызван по итого. Как он будет вызван уже не интересно.
В конце теста создания, например, добавляю ожидание на нужный сервис, который должен был вызван по итого. Как он будет вызван уже не интересно.
а если асинхронка? вызовется только паблиш, а дальше вообще никого не волнует кто получит сообщение, кому надо тот получит, мне кажется это не задача того кто паблишит проверять кто получит
IG
Есть подходы, когда весь реквест оборачивается в транзакцию. И тогда в коде флаши появлялся только в очень специфичных местах. Например, таких.
IG
а если асинхронка? вызовется только паблиш, а дальше вообще никого не волнует кто получит сообщение, кому надо тот получит, мне кажется это не задача того кто паблишит проверять кто получит
По бизнес логике после создания пользователя нужно отправить уведомление.
Тест, проверяющий создание, в конце ставит ожидание, на сервис доставки.
Если асинхронно, то на сервис добавления асинхронных сообщений в очередь.
Тест, проверяющий создание, в конце ставит ожидание, на сервис доставки.
Если асинхронно, то на сервис добавления асинхронных сообщений в очередь.
D
По бизнес логике после создания пользователя нужно отправить уведомление.
Тест, проверяющий создание, в конце ставит ожидание, на сервис доставки.
Если асинхронно, то на сервис добавления асинхронных сообщений в очередь.
Тест, проверяющий создание, в конце ставит ожидание, на сервис доставки.
Если асинхронно, то на сервис добавления асинхронных сообщений в очередь.
ага, понял идею. благодарю
IG
Но если в подписчике есть логика, а не только реакция на сообщение, то его тоже надо тестировать.
А общем, всегда два типа тестов идут рука об руку: проверяющие функционал, и проверяющие компоновку приложения.
А общем, всегда два типа тестов идут рука об руку: проверяющие функционал, и проверяющие компоновку приложения.
МФ
The Ant 🐜
потому что ебал ваш опенсорс, вот почему. Говнари делают для говнарей. А потом грудь колесом.
—
SP
Сам удалишь сообщение?
JB
Нормальное эмоциональное сообщение - не нуждается в модерирование
VK
Пошел чинить опенсорс))099
ВМ
Он точно программист? ))
JB
пограммист
МФ
Сам удалишь сообщение?
Ок
2020 October 05
AN
Подскажите плизз, если я использую AbstractGuardAuthenticator, то мне в любом случае нужно будет делать UserProvider?