Skipper.LiveViewTest (skipper v0.3.0)
A set of helper functions that make LiveView tests easier to read and write as a pipeline without leaking details of the conn, view, rendering, patching, etc.
To use in your tests, you may replace:
import Phoneix.LiveViewTestwith (using the helpers takes care of the import for you):
use Skipper.LiveViewTestAnd then write tests like:
test "a view", %{conn: conn} do
start(conn, "/")
|> assert_visible("Something")
|> click("Edit")
|> assert_visible("Editing Something")
endLink to this section Summary
Functions
Assert that some selector with the (optional) content exists in the view. You may notice the similarity of this function to assert_visible/3. The downside of this function is that assertion failures to not provide as specific feedback (due to the difference in implementation). The advantage is that it may be used to assert in elements that appear repeatedly by their selector.
Assert that some content exists in the view.
Assert that some selector exists in the view whose (optional) content matches. You may notice the similarity of this function to assert_element/3. The advantage of assert_visible/3 becomes apparent when the assertion fails. This function provides and more specific failure message, i.e. "here's the element that was found" vs. "the expected element simply doesn't exist on the page".
Change a form and render the change so that assertions may be made about the result.
Locate an element on page an issue a phx-click event. If the system redirects, automatically follow the redirects (recursively) until a view is rendered.. If it simply renders, the new rendered view is returned.
A small utility function that makes it easy to assert HTML as a string.
The opposite of assert_element/3.
The opposite of assert_visible/2.
The opposite of assert_visible/3.
Simply rerender the LiveView. In some test, there are background events that trigger changes to the view, this functions provides a mechanism to render the view again after such an event in your test.
This function is the "helpers" analog of LiveView's live/2 function.
Submit a form and follow its redirect.
A utility function that makes it easy to open the current view up in a browser for visual debugging as you write your test. No more than a small wrapper over the open_browser/1 function you may already be familiar with.
Link to this section Functions
assert_element(arg, selector, text \\ nil)
Assert that some selector with the (optional) content exists in the view. You may notice the similarity of this function to assert_visible/3. The downside of this function is that assertion failures to not provide as specific feedback (due to the difference in implementation). The advantage is that it may be used to assert in elements that appear repeatedly by their selector.
example
Example
# Given some multi-select
|> assert_element("option[selected]", "Picked")
# Would pass if there is any selected "option" that matches the text
# "Picked". While assert_visible/3 in this case would fail when there are
# multiple selected options on the page at all.assert_html(session, expected)
assert_path(arg, path)
assert_visible(arg, expected_html)
Assert that some content exists in the view.
Note: At this time, the assertion will match any part of the entire page document as a string which does not precisely align with the "visible" part of the function name. This is a known issue and is on the slate for discussion.
assert_visible(arg, selector, expected_html)
Assert that some selector exists in the view whose (optional) content matches. You may notice the similarity of this function to assert_element/3. The advantage of assert_visible/3 becomes apparent when the assertion fails. This function provides and more specific failure message, i.e. "here's the element that was found" vs. "the expected element simply doesn't exist on the page".
Note: At this time, the assertion will match any part of the entire page document as a string which does not precisely align with the "visible" part of the function name. This is a known issue and is on the slate for discussion.
change_form(arg, selector, attributes)
Change a form and render the change so that assertions may be made about the result.
Locate an element on page an issue a phx-click event. If the system redirects, automatically follow the redirects (recursively) until a view is rendered.. If it simply renders, the new rendered view is returned.
escape(html)
A small utility function that makes it easy to assert HTML as a string.
Note: I am considering a sigil for this case. It requires more research.
example
Example
|> assert_visible("can't be blank")
|> assert_visible(escape(can't be blank"))refute_element(arg, selector, text \\ nil)
The opposite of assert_element/3.
refute_html(session, expected)
refute_visible(arg, unexpected_html)
The opposite of assert_visible/2.
Note: At this time, the assertion will match any part of the entire page document as a string which does not precisely align with the "visible" part of the function name. This is a known issue and is on the slate for discussion.
refute_visible(arg, selector, unexpected_html)
The opposite of assert_visible/3.
Note: At this time, the assertion will match any part of the entire page document as a string which does not precisely align with the "visible" part of the function name. This is a known issue and is on the slate for discussion.
rerender(arg)
Simply rerender the LiveView. In some test, there are background events that trigger changes to the view, this functions provides a mechanism to render the view again after such an event in your test.
This function is the "helpers" analog of LiveView's live/2 function.
Submit a form and follow its redirect.
view_in_browser(session)
A utility function that makes it easy to open the current view up in a browser for visual debugging as you write your test. No more than a small wrapper over the open_browser/1 function you may already be familiar with.