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})
  end

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

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

    {:ok, state}
  end

  ...
end

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, _}
end

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
(GenServer — Elixir v1.20.2)