Skip to content

have_element is a bit more confusing than be_on_page #150

@jwoertink

Description

@jwoertink

In this PR #135 be_on_page was removed in favor of have_element. This ended up being a breaking change. When trying to fix the specs, I found it really confusing on how to properly use this.

https://github.com/luckyframework/lucky_cli/blob/620ca03e9a783f3f70e2a5109765b8912f52cfb8/src/browser_authentication_app_skeleton/spec/support/flows/authentication_flow.cr#L29-L35

def should_be_signed_in
  sign_out_button.should be_on_page
end

def should_have_password_error
  el("body", text: "Password is wrong").should be_on_page
end

These end up becoming

def should_be_signed_in
  self.should have_element("@sign-out-button")
end

def should_have_password_error
  self.should have_element("body", text: "Password is wrong")
end

You could have the implicit self, but just having the floating should outside of a spec feels weird. The other thing is, before it read like the flow was expecting to find the element on the page. Now it reads as if the flow itself should have this element, but it's not really the "flow" object that has the element, it's the page that's being parsed by the flow.

I think for now, I'll create a shim for readability

private def current_page
  self
end

current_page.should have_element("@sigh-out-button")

Another nice update we could have is maybe an override that allows have_element to take a flow.el().

def should_be_signed_in
  current_page.should have_element(sign_out_button)
end

private def sign_out_button
 el("@sign-out-button")
end

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions