It provides a "page object model" implementation on top of Capybara, so you can define a model for each page you want to test, which stores the page's relative URL, and has references to all the elements on the page you care about, and methods for all the interactions you want to do with that page.
So for example, you might have a "LoginPage" model, which contains the following:
class LoginPage < SitePrism::Page
set_url "/login"
element :username_input, '.username-input'
element :password_input, '.password-input'
element :submit, '.submit-button'
def login(username, password)
load # Load the page URL in the Selenium instance
username_input.set(username) # Fill in username
password_input.set(password) # Fill in password
submit.click # Click submit
end
end
Then whenever you want to login from one of your steps, you can just do:
I think it's a nice abstraction as it allows more experienced test automation developers to build the page model while less experienced ones can write steps just calling the methods. You still have to pay a lot of attention to things like appropriate use of "wait for element to appear" rather than "sleep", and ensuring tests use isolated data, to get it working reliably, but we've got it working pretty well at my current place.
I should write up how we have it set up at some point as we have our own app-specific framework on top of SitePrism which provides some useful abstractions to make it quicker to develop tests.
It provides a "page object model" implementation on top of Capybara, so you can define a model for each page you want to test, which stores the page's relative URL, and has references to all the elements on the page you care about, and methods for all the interactions you want to do with that page.
So for example, you might have a "LoginPage" model, which contains the following:
Then whenever you want to login from one of your steps, you can just do: I think it's a nice abstraction as it allows more experienced test automation developers to build the page model while less experienced ones can write steps just calling the methods. You still have to pay a lot of attention to things like appropriate use of "wait for element to appear" rather than "sleep", and ensuring tests use isolated data, to get it working reliably, but we've got it working pretty well at my current place.I should write up how we have it set up at some point as we have our own app-specific framework on top of SitePrism which provides some useful abstractions to make it quicker to develop tests.