Testing patch navigation triggered by the Phoenix link component in LiveViewTest

Phoenix Forum Questions / Help
, , , , , ,
1

Hello!

I’m still a newcomer to Elixir and Phoenix, I’ve only started using them early this year. So asking kindly for understanding if the question I ask turns out to be trivial :sweat_smile:

The app I’m now working on in my project has several buttons which serve as links to patch the current LiveView (which results in UI changes, e.g. tab change in a menu). In its simplest form, the pattern is as follows:

<.link patch={~p(/users/#{@id}/edit)}>
  <.button>
    Edit
  </.button>
</.link>

The issue I’m currently facing is how to properly test such components - specifically, how to test that pressing this link will result in a patch as expected. Basically, I’d like to test the following series of events: (1) open view → (2) assert some html → (3) click link → (4) assert patch → (5) assert some different html. So step #3 is where I’m currently stuck at.

render_click won’t do in this case, since the Phoenix.Component.link/1 component does not have a phx-click attribute. Looking through the Phoenix.LiveViewTest documentation, I didn’t find anything that seems to work specifically for links.

Of course, the two less-than-satisfying options that come to mind now are:

  1. Not test interacting with the link directly and just simulate the resulting patch with render_patch/2 (seems like this reduces test reliability since the patch link is dynamic, dependent on assigns)
  2. Replace all instances of the above pattern with regular buttons with phx-click, and trigger the patch in the event handler (much better option from test reliability perspective, but modifying app code solely for testing purposes is probably not ideal, unless necessary)

But before I go with either option I wanted to ask here - is there any way to test patch navigations triggered by Phoenix link components in LiveViewTest that I’m missing?

2

Hello and welcome to Elixir Forum!

render_click should absolutely work on a <.link> component. Are you using element first?

lv
|> element("#my-link")
|> render_click()

assert_patch(lv, ~p"/users/#{@id}/edit")

assert render(lv) =~ "some html"

Also, just in case you weren’t aware, assuming you have a @user assign you don’t need to bother assigning @id as well, you can pass an Ecto struct to verified routes and it knows to use its id:

patch={~p(/users/#{@user}/edit)}
1 Like
3

Hey, thanks for your response!

You are absolutely correct. I wrote this post because I kept getting a (paraphrasing) “element does not have phx-click attribute” error, but apparently it was because I had an issue with my selector in element - I used a straightforward id this time and now it works!

Of course, now that it works I noticed that there is the below clear paragraph in the docs:

If the element does not have a phx-click attribute but it is a link (the <a> tag), the link will be followed accordingly

So if I just read a bit more, I’d realize the issue was somewhere else, and not with render-click. Lesson for the future, I guess. Thanks for taking the time to help out!

As to your second point - I simplified the code snippet, we use @user.id, but I was actually unaware of the option of passing an Ecto struct to verified routes. I’d like to read more about it, is this what you’re referring to? Phoenix.Param — Phoenix v1.7.12

1 Like
4

Yep! Derive Phoenix.Param to use another field. It’s legit to do @user.id too but it does make refactoring much easier if you ever want to switch to @user.slug or something.

1 Like