Following redirection in ControllerTests

Say I have a controller like so.

  def create_pass_reset(conn, %{"user" => %{"email" => email}}) do
    case Accounts.reset_pass(email) do
      {:ok, user} ->
        |> put_flash(:info, "Password Reset Sent to #{}")
        |> redirect(to: session_path(conn, :new))

Note that I am setting a flash on a conn that is due to be redirected.

And say I have a test like so.

test "POST /password-reset", %{conn: conn, user: user} do
  conn = post conn, user_path(conn, :create_pass_reset, %{"user" => %{"email" =>}})
  assert redirected_to(conn, 302) =~ "/login"
  assert html_response(conn, 302) ==  "Password Reset Sent to #{}"

Well clearly the issue with this test is that the conn does not contain the state after the redirection occurred and thus does not have the content we are looking for


 Assertion with == failed
 code:  assert html_response(conn, 302) == "Password Reset Sent to #{}"
 left:  "<html><body>You are being <a href=\"/login\">redirected</a>.</body></html>"
 right: "Password Reset Sent to"

So my question is, how do I perform the redirect so that I can see the state after the redirection has occurred?


Something like this should work:

conn = post conn, user_path(conn, :create_pass_reset, %{"user" => %{"email" =>}})
assert "/login" = redir_path = redirected_to(conn, 302)
conn = get(recycle(conn), redir_path)
assert html_response(conn, 302) ==  "Password Reset Sent to #{}"

Gonna have to use that assert / assignment again, assert "/login" = redir_path = redirected_to(conn, 302) :tada:
Thank you yet again @chrismccord

Also what are your thoughts about this pattern of following the redirect?
This is something I’ve yet to see in the community.

It’s just fine pattern wise. It’s not exactly the same, but our context generators make use of redirected_params to construct a path and then get the show page of a created resource:

1 Like

Sorry to bug you again on this. I’m struggling with something when maintaining state.

I get the principle of saving conn.assigns to save authentication to reuse with different calls. I’m probably misunderstanding, but how do I make sure the validation errors don’t get tossed. Or the 302 is follow without recycling (I think this would solve it)?

The below is the code in question, there is a setup [:create_user] for the describe block.

@tag :authenticated
test "renders errors when data is invalid", %{conn: conn, client: client} do
  conn = put(conn, client_path(conn, :update, client), client: @invalid_attrs)
  assert html_response(conn, 200) =~ "Edit Client"

This gets a 302 and “you are being redirected”.

Getting the same thing.
<html><body>You are being <a href="/auth?redirect_to=...">redirected</a>.</body></html>

I’m having a hard time understanding the question. From what I can understand from the code is that you want to assert that if you are passing in invalid_attrs to the update function than the html response should be a 200 and include the text edit client.

I assume that to be a correct assertion of what you are expecting from that controller function. Sadly without seeing that functions definition I can’t say as to why its returning a 302 with the text your are being redirected.

I’m also not sure why you are referring to the recycle function . In my case I was prescribe that method because it allowed me to make a follow up request on that same conn in my test which was to follow the redirection so that I could see the follow up page and assert on the flash message of that completed redirection.

Though if I assume you are passing in bad attrs into a update action you would not want a 302 redirection on that post.

Is it possible you are in a redirection loop?
Edit: Don’t laugh it happens.

I think you’re right. That redirect is to /auth path, so my test was probably lacking a current_user. My bad :stuck_out_tongue:

Actually, I just tried it on another endpoint of mine and had the same issue.

Is it possible that by calling recycle(conn) we lose the previously assigned current_user?

Yes indeed, recycle/2 gives you a fresh connection with no assigns, so you need to save them prior to calling it and make sure you put them again. I encountered the same scenario and found a solution here: Why Phoenix Recycling?