Page Objects / Framework

Question 1

What is PageObjects Model?

Answer 1

It’s essentially mapping the models/classes/pages of your framework to the model of your web pages.

For example, a Login Page. It has the same functionality as your application’s login page. It’s responsible for getting the elements that exist on that page, and manipulating them.
It works at a high level. For example, in my tests I won’t write “enter username, enter password”. I’ll handle all that in my Login Page and expose a simple LOGIN method with maybe a restricted set of options (reduce the number of parameters for an API call).
Pages can also map to common workflows, for example a Shopping Cart (which doesn’t have a specific page), or general navigation workflows.

I also didn’t include the Selenium dependencies in my tests. It was only in the framework.

I tried a couple of different designs. One was to define my PageObject methods as class methods, so I didn’t need to instantiate in my tests (this would be like static methods in C# or Java). This makes my tests a kind of pseudo-DSL, plain English and easy to write.

Question 2

What is a benefit of PageObjects?

Answer 2

If you have query logic or element selection logic in a few different places in your tests, if something changes in the AUT then you’ve got a lot of broken functionality.  The framework acts a as a buffer between your tests and your application.
DRY principle (from Rails)

It also helps simplify the tests themselves. The syntax is a kind of pseudo-DSL.

Question 3

How do you organize your test cases, suites, and framework?

Answer 3

It’s usually a hybrid style framework. PageObjects, workflows, utility classes, etc., all as part of a framework separated from the test cases.

Use RSpec or Test::Unit, each test case class just inherits from the respective TestCase class.
Each test case inherits from a BaseTest class, where I’ll require all my dependencies (framework, gem, etc.), and define my setup and teardown functions (clean up methods in the framework, driver close).

I’ll include the Assertions from Test::Unit. Most of these Test driver classes have their own command line drivers, so I could run there.

I’ve used Cucumber in the past which has nice output options and PageObject instantiation (using Cucumber’s world object).

I would probably have a BasePage also, and each page object would inherit from that. I’d define common navigation workflows, etc. Or just require them there so that all the PageObjects would have access to them.

In my framework I’d also have DataGenerator objects, if I didn’t care about the data, or to pinpoint where the data is coming from (useful for debugging). Faker gem is what I’ve used in the past, but I could also generate data from useful websites (mockaroo, lorem ipsum, etc.), or Factories.