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.
