#elixir #phoenix-framework #phoenix-channels #ex-unit
#elixir #phoenix-framework #phoenix-каналы #ex-unit
Вопрос:
Я провожу тест канала, который получает много сообщений. Я могу получить сообщение во время настройки, настроить какое-то состояние, а затем я хочу, чтобы assert
(или refute
) была отправлена другая копия этого сообщения. Я думаю, что мог бы сделать это, очистив почтовый ящик перед вызовом события, которое вызвало бы второе сообщение. Как мне очистить channelcase
почтовый ящик?
РЕДАКТИРОВАТЬ, я выполнил свои потребности, assert_push
удалив все старые сообщения, которые удаляются из почтового ящика. Это работает достаточно хорошо, но было бы очень неудобно, если бы было больше нескольких сообщений
Ответ №1:
Просто чтобы уточнить, не запутался ли кто-нибудь, кто мне нравится, в этой проблеме.
Сообщения, отправленные по каналу, хранятся в почтовом ящике процесса тестирования, поэтому для очистки сообщений нам просто нужно очистить почтовый ящик процесса. Итак, используя то, что указано выше, мы можем удалить сообщения.
P.D: С помощью этого :erlang.process_info(self(), :messages) |> IO.inspect()
мы можем видеть текущие сообщения в почтовом ящике процесса.
Ответ №2:
Редактировать: :lib.flush_receive()
работает отлично! К сожалению, похоже, что модуль устарел, и я не могу найти замену.
Я искал решение этой проблемы. assert_push
для меня непрактично, поскольку есть много сообщений, которые находятся в очереди и не имеют отношения к моему тесту. Вы можете использовать :c.flush()
который сбрасывает все сообщения. К сожалению, я пока не знаю, как предотвратить вывод этого файла на консоль.
Комментарии:
1. вы пробовали hexdocs.pm/ex_unit/ExUnit.CaptureIO.html#content ?
2. У меня нет. Как это поможет?
3. «К сожалению, я пока не знаю, как предотвратить вывод этого файла на консоль». не уверен, что ваша правка решила эту проблему, но я считаю, что CaptureIO может предотвратить печать сообщений в консоли
4. О, я понимаю, что вы имеете в виду. Я мог бы попробовать это, да. :lib.flush_receive(), который я отредактировал, решает проблему на данный момент. Если это исчезнет в следующем обновлении erlang, я могу попробовать упомянутый вами CaptureIO.
Ответ №3:
Простой способ добиться этого — просто получить %Phoenix.Socket.Message{}
.
Например:
def flush_messages(timeout \ 100) do
receive do
%Phoenix.Socket.Message{} ->
flush_messages()
after
timeout -> nil
end
end
timeout
Предназначен для того, чтобы разрешить получение ожидающих сообщений. 100m также является таймаутом по умолчанию для assert_receive
, который используется assert_push
.