Как очистить почтовый ящик в тесте channelcase phoenix Framework

#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 .