I’m working on a multiple-choice quiz application that uses LiveView for its interface. The questions are randomly selected from a larger set, and then stored in the socket’s assigns, along with their answers.
When testing the LiveView, I’d like to look at a question contained in the assigns (and along with it, its answer), so I can then test what happens when a right answer or wrong answer is selected by the user. However, I don’t see an easy way to access the socket and its assigns from the test case itself – just the HTML of the rendered view.
Am I missing a simple way to get at socket.assigns in a Phoenix.LiveViewTest, or will I need to mock the quiz interface so it always returns something non-random in the test environment?
Interesting. The conn before the {:ok, view, html} = live(conn, "/quiz/") call has empty assigns, and the live(conn, "/quiz/") call doesn’t return an updated conn, just the view and the rendered html, so I was going to say the conn object wasn’t even available to the test.
But if I break up the call to live by doing a conn = get(conn, "/quiz") followed by {:ok, view, html} = live(conn), then that intermediate conn does indeed have the data I’m looking for in its assigns.
Thanks for the poke, I’d been assuming conn.assigns both wasn’t available and wasn’t related to the socket.assigns anyway.
I’m still not sure how to access the assigns later on, after they’ve been changed by some handle_event calls, but that doesn’t matter for this test.
Note that you should test the results of the LV rendered content rather than the assigns. Reaching into the assigns is internal state and will lead to a brittle test. So using the render_* functions and asserting on the expected side effects is the way to go
I do get that the structure of assigns is a lot more likely to change than the contents of the view, and that other people working on the same code might not expect the tests to depend on the structure of assigns. But since we’re here, here’s my passing test:
test "correct answer clicked", %{conn: conn} do
conn = get(conn, "/quiz")
{:ok, view, _html} = live(conn)
correct_answer = conn.assigns.correct_answer
expected = "Congratulations! You got it right!"
assert render_click(view, :answer, %{option: correct_answer}) =~ expected
end
The value of correct_answer is determined by a quiz-generating call during the mount and is completely random – while the answer to ‘What sound does a cat make?’ will always be ‘Meow’, sometimes that’ll be the first answer, sometimes that’ll be the second answer, etc.
I don’t consider myself particularly skilled here, so this is my chance to learn something – instead of doing what I’ve done, how would you test something like this? Mock the quiz-generating function? Pass an anonymous answer-sorting function to the quiz-generating function as a variable, and use a deterministic one in test? Click on every link, add up the results, and assert that the ‘correct answer’ result happened once and only once? Change the implementation so the correct answer isn’t in the assigns at all, but fetched from the backend after every answer? I considered all of these instead of dipping into the assigns, but didn’t love any of them – the increased complexity didn’t seem worth it.
TL;DR, LiveViewTest’s purpose is to test the simulated effects of network requests.
LiveView tests—while not quite end-to-end tests—are meant to test what the user sees, not the internals. We can see this with the form/3 function not allowing us to fill in hidden fields. We also get a good hint with all the render_ functions that LiveViewTest gives us that are always called just before an assertion. At this abstraction level, the fact that the returned compiled templates are the result of side-effects isn’t important.
You can even see this with how LV tests are written:
{:ok, lv, _html} = live(conn, "/")
lv
|> element("a")
|> render_click()
lv # <-- `lv` here is the result of the side effect of `render_click`
|> form("form", %{name: "Bob"})
|> render_submit()
While we know the lv variable itself and its value have not been mutated, the process belonging to the pid it holds has! (or like, you know, it’s been “functionally updated” but for all intents and purposes we could say it has been mutated).
If you want a hack approach to access assigns I think you can have it by the conn struct or doing:
:sys.get_state(lv.pid).socket.assigns if I am not wrong.
But that is not a good approach since LV test you should follow an approach simulating the user interaction with your app using the render_* functions.
Template changes resulting from an event are not side effects. They are the main effect, i.e. the final action of the live action. The template reflects the changes that occur as a result of the handle_event. How exactly those changes happen shouldn’t be relevant to your tests.
To come at it from a different perspective: When a user clicks a button on the page, they are concerned with what changes they see as a result. They do not care what your assigns are named or what goes on inside the handle_event function. Therefore, neither should your tests.
Suppose you have template that shows a list of ToDo items with their count in the top left corner, and there’s a button that lets you add a todo item with a given name. A proper test would be to call render_click on the ‘create’ button and assert that the ToDo list contains a new item with the given name, and assert that the new count appears somewhere on the page. A brittle test would be to test that assigns.todo_items contains the new todo item and assigns.to_do_count is original + 1. The former is what the user cares about. The latter is an implementation detail, and such a test will break if, for example, the assigns are renamed during a refactor.
test "connected mount", %{conn: conn} do
{:ok, view, _html} = live(conn, "/my-path")
assert view.assigns[:some_key] == expected_value
end
The reason I want to do this is that I have a parent LiveView with a couple of children. I want to send a message to a child to refresh when something happens in the parent. To do this, I need the child to have a unique ID so I can send it a message without sending that message to other children on the server with that same id (pretty sure this is how it works?). I don’t want to load the data in the parent because the children are somewhat complicated and the code is nice if they load their own data.
In the LiveView test, I need access to the child using find_live_child and to do that I need its id. Which is stored in the assigns.
I wrote all that up because I think it’s a valid reason to need access to the assigns, and also because maybe my overall approach isn’t right and someone can tell me.
Update: I’m going to have the child LiveView register with its parent instead of looking up the pid. I think this will be more elegant and make it so I don’t need that unique id on the child.
For anyone reaching this forum post because they wanted to test a part of a LiveView / Live Component, for example the ‘handle_event/3’ implementation, this is how I wrote one of my tests:
test "raises an error if user is not authorized to delete the upload",
%{conn: conn, user: user} do
recipe = insert(:recipe, status: :draft, author: user, cover_image: insert(:cover_image))
socket = %Phoenix.Socket{} |> Phoenix.Socket.assign(recipe: recipe)
assert_raise MyApp.Media.NotAuthorizedError, "not authorized", fn ->
BadgerWeb.Recipes.CoverImageUploadComponent.handle_event("delete-upload", %{}, socket)
end
end
