What is Capybara::UI's killer feature?

[laserlemon]

Capybara::UI has been fun to hack on but I want to make sure it's providing some real value/benefit before 1.0 ships.

Using the same recommended file structure for defining Capybara::UI classes, one could instead define simple helper methods.

module LoginHelpers
  def log_in(email, password)
    # TODO
  end
end

This could achieve pretty much the same results as using Capybara::UI but without the driver restrictions and magic. Not exactly the same, but close!

What advantages (if any) are there in having page objects rather than "global" scope helper methods?

Thoughts?

[ersatzryan]

I think this is the same argument as presenters vs helpers. It isn't a killer feature so much as it is creating concise well formed objects just as we do with our code. With our DOM being represented by objects it gives us the ability to do object composition and inheritance, as we would with presenters.

If a multitude of pages have a navigation menu then we can extract those methods into an element or into a module that is included into each of those pages so that testing things such as the current nav item is as simple as page.ui.current_nav or something similar. This does not pollute our spec scope with helpers when the pages we are interacting with do not have those items or need them.

[asheren]

Hi there! We're doing some open source maintenance work and closing old issues. If this issue is still applicable or you would still like it to be addressed, please re-open the issue by April 17, 2017. Thanks!