View Source Assertions Cheatsheet

These ways of asserting in tests give you some advantages over the "standard" way:

  • Better errors. Most of these recipes rely on ExDoc to provide better errors when a test fails (except for is_in?/2 which is just a convenience function).
  • Forces you to be more specific about what you are testing. The usual way of using render(view) =~ expected_content is prone to false green and, when failing, makes it harder to know the intent of the test.

Elements existence

is_in?/2

Just a convenience function that reverses the arguments of Phoenix.LiveViewTest.has_element?/2.

assert "input"
  |> with_attrs(type: "checkbox", name: {:ends_with, "[type]"})
  |> is_in?(view)

Check the number of elements matching a selector

Other comparisons are possible, like greater than or less than.

assert find_count(view, "[data-test=accordion]") == 2

Elements attributes

Checking it has a class

assert selector
  |> with_class(expected_class)
  |> is_in?(view)
assert expected_class in (find_first(view, selector) |> classes() |> List.first())

Checking it has certain attribute

assert selector
  |> with_attr("aria-expanded", "true")
  |> is_in?(view)
assert [["true"]] ==
  attribute(view, selector, "aria-expanded")

Checking the text of an element

When fails, you get a nice diff between both text. Also, =~ is prone to false greens.

assert text(view, "[data-test=my-element]") == "My content"

Multiple checks at once

No better errors here, except for text.

selector = "button" |> with_class(".destroy") |> with_attrs(disabled: true, type: "submit")

assert text(view, selector) == "Submit form"