assert_path doesn't work with live navigation

[randycoulman]

I've run into a few places where I've tried to use assert_path and it hasn't produced the results I've expected.

I can try to put together a reproducible example if that would help, but I think you'd be able to reproduce these results using a generated LiveView. Basically, anywhere the generated tests use assert_patch are places where assert_path would fail.

A few examples:

• I have a <.link patch={~p"/thingy/new"}> in my app. If I click_link on that link and then try to assert_path(~p"/thingy/new"), the assertion fails because the path is still the original ~p"/thingy".
• I have a form where you enter a value. If the value is valid, we to a push_patch to the same route, but with the value included as a query param (i.e., push_patch(socket, to: ~p"/my/current/path?value=42")). If I try to assert_path(session, ~p"/my/current/path", query_params: "value=42"), I get an error because the query params are not present.
• I show an edit form in a modal (like the liveview generator produces). After saving the changes, the code does a push_navigate back to the original route. However, in the test, after clicking the Save button, assert_path fails because the path is still the edit path. Every other assertion I make shows that the modal was closed and I'm back on the original page with updated values, but the path is wrong.

It looks like assert_path is using conn.request_path, but PhoenixTest's follow_redirect isn't actually updating and returning the conn, so the request_path doesn't change. Given that, I'm not sure what the best solution for this problem is, but it makes it so that assert_path is not usable with live navigation.

[germsvel]

Thanks @randycoulman! Yes, this makes sense. We're just relying on conn.request_path to get the "current" path. We'll have to update that to handle patches.