How to keep a websockex client connected?


I’m learning elixir and the current use case I’m now playing with is a websocket server with plug_cowboy and a client with websockex. Server is working nice if I test with websocat or other clients.

My main issue is that while coding a simple test case where the client sends a message and the test finishes (ends the process, as I understand, which may be wrong) before actually receiving the response. I suspect I’m missing some kind of loop that keeps reading the socket for incoming messages instead of just sending a message and finishing the process [because no more code is left to be run].

My code is as follows, test client first:

  use WebSockex
  require Logger
  def start(url, state) do
    WebSockex.start(url, __MODULE__, state)

  def request(client, message) do"Sending request: #{inspect message}")
    WebSockex.send_frame(client, {:text, message})
  def handle_connect(_conn, state) do"Connected")
    {:ok, state}
  def handle_frame({:text, msg}, state) do "Received a message: #{inspect msg}"
    {:ok, state}

  def handle_cast({:send, {type, msg} = frame}, state) do
    IO.puts "Sending #{type} frame with payload #{inspect msg}"
    {:reply, frame, state}

  def terminate(_reason, _state) do

And the test:

    {:ok, pid} = Client.start("ws://localhost:4444/", %{})
    Client.request(pid, Jason.encode!(%{msg: "hi there"}))
    # something missing here to keep Client connected and later call Client.stop

Thanks in advance!

If I understood correctly, you have a local websocket server, made with cowboy and plug_cowboy. After you call Client.request/2, you expect that the client receives a websocket frame from the server right? What exactly do you want to test, which assertion?

(Currently) The server is just an echo server, so I want to assert in the test that the server sent back the same the client sent first. By looking at the server logs, the message is received and replied, but (coming from other languages) client side I’d expect the client to remain connected to the websocket and see how the reply is logged,at least to stdout :slight_smile:

I’m probably missing something very basic here, to the extent that my problem may not be understood. Please ask me to clarify whatever makes no sense!


The Client is asynchronous, so when you make a request/2 the process of that test ends without waiting for any answer, bringing everything down (and closing the connection). So, the quickest way to see the log, to see if your experiment works, is to use iex (the elixir interactive console) and start the client there.

If you really need to make a real unit test, the frames the Client receives from the server are internal. You shouldn’t test directly those messages, instead I would test the client’s interface.

Ok, so let’s say you want to keep everything asynchronous and, as part of the implementation of your Client, you want that the client forwards to a process each websocket frame:

defmodule Client do
   def start_link(url, send_to_pid) do
    WebSockex.start_link(url, __MODULE__, %{send_to_pid: send_to_pid})

  def handle_frame({:text, msg}, %{send_to_pid: pid}=state) do "Received a message: #{inspect msg}"

    send pid, {:websocket_msg_received, self(), msg}

    {:ok, state}


test "receives message from the client when a websocket text frame is received" do
    {:ok, pid} = Client.start_link("ws://localhost:4444/", self())
    Client.request(pid, Jason.encode!(%{msg: "hi there"}))

    assert_receive {:websocket_msg_received, ^pid, _}

When you start the client, you pass self(), which is the test process pid. When the client process receives a websocket frame, it sends a message to send_to_pid. With assert_receive the test waits that the message is received.

As you can see in handle_frame/2, the client sends also its pid (self()) as part of the message. In this way we can pattern match it with assert_receive to be sure that the pid is the same of the client we started.

PS: use start_link so what you spawn is a linked process. In this way when test exists it brings down your client process.

Note that a GenServer started with start_link/3 is linked to the parent process and will exit in case of crashes from the parent

1 Like

Thank you so much for the detailed explanation. Really appreciated :slight_smile:

I got it working with your indications. Still need to grasp what seems to me the “all is a process” motto and so I need to be sending messages all along to interact with the different elements.

Best regards.