Page-Object model integration

[chadbrewbaker]

This is the closest thing that came to an idea I had for a testing framework. Dominos is a good metaphor to visualize it.

We had a 30+ page deep application for insurance agents to get quotes, not your Amazon style 3 clicks gets you anywhere. We could easily map the tests to the pages with the page object model. The flows between pages however were a beast, and too much behavior was hard coded into the page object instead of being consumed from a test configuration file.

I want a testing framework that asks two simple questions when defining flows, we could call these the domino questions.

1. What page object did you come from?
2. What actions did you do on that page to get to this page?

Your framework is close, but not quite there. Also, you need a serialized format for things like click actions so they can be read as data, not hard-coded in Capybara.

[ngauthier]

Yeah it's hybridized enough with the ActiveRecord style that it's not true page objects. I've never written anything as deep as 30 pages to perform an action, but when I do have more complicated actions I write macro methods in my test helpers. Then I combine them and nest them so my tests read more like:

admin_logs_in
issue = create_issue(description: "app keeps crashing!")
rep_logs_in
visit issue_path(issue.id)
assert page.has_content?("app keeps crashing!")

So the setup lines use my helpers then the non-repetitive stuff that is specific to the test is near the end.

I appreciate the comments and the feedback, but this is not an issue so I will close it. However feel free to keep writing here to continue the conversation (I just don't want to think it's an open bug or something :D )

[chadbrewbaker]

I think I understand your framework a bit better. The domino is the equivalent of a page object?

I use the term "page object" very generically to mean a partition of the user facing interface. That way it encompasses the test space of command line apps and monolithic single page apps.

Macro methods are hard to maintain at scale. Ideally you want some data driven "tour" templates like Google uses. http://googletesting.blogspot.com/2011/01/how-google-tests-software.html From those you can tailor them with small patches to get your application in the goal state.

[ngauthier]

A domino is analogous to a single piece of data on the page, not a part of the ui. So you would have dominos for a Person in a table, or a Product in a list, or maybe a single Item when you are viewing something in a store.

Dominos don't work as well on forms or control panels, but they can be used on them. Dominos have three primary powers:

1. Ability to use a selector to turn 1-many objects on the page into individual ruby objects
2. Additional selectors for attributes to turn data within the object into a ruby primitive
3. Providing the capybara root node of the object in order to interact with ui inside the object easily using the node as the scope

For interacting with forms, you could use a domino, but often simply using capybara's within is easier. Plus using ruby blocks you can do stuff like:

def within_signup_form
  within "#content #signup-form" do
    yield
  end
end

within_signup_form do
  fill_in "Email", with: "nick@example.com"
end

which is a lot simpler than using a domino for the form would be.

[ngauthier]

p.s. I always use helpers to abstract css selectors when I reference them more than once. css selectors are data, so using them multiple places is not DRY as changing the selector on the site would mean multiple test changes. Tests are code too.